so i have an problem i want to remove jailbreak from mine iphone 6s it has IOS 15.3, would restoring the ipsw restore the rootfs too??
I have tried to restore the iphone from settings but it didnt unjailbreak.
Thank you!
Unjailbreaking your device is usually done by restoring an APFS Snapshot made by the jailbreak tool before jailbreaking the device.
Normal jailbreak procedure requires the tool to drop a binary pack and a bootstrap onto the file system. This includes the tweak injector binary and libraries (Substitute, Substrate, LibHooker, etc), and the support binaries (standard Unix tools, etc.).
These would normally only be injected into the File System once, then re-jailbreaking after reboot just runs the exploit and the in-memory patches.
Restoring the APFS Snapshot to the clean one is done directly from the jailbreak tool.
For Unc0ver jailbreak, in Unc0ver's Settings page there's a toggle called "Restore ROOT FS". Once you toggle that on, and go back to the main jailbreak screen, the big blue button changes from "Jailbreak" to "Restore ROOT FS". Press it, wait for the reboot and once the device has rebooted, you're now stock iOS with no trace of the jailbreak left.
For Odyssey and Taurine Jailbreak is the same thing. The ROOT FS restore toggle is in Settings.
For CheckRa1n Jailbreak, there is no toggle. While being jailbroken, open the CheckRa1n app on your iOS device and press "Restore System". It's the red button at the bottom.
After the reboot, there will be no trace left of the jailbreak.
Erasing all contents from Settings may NOT remove the jailbreak files from the FS completely.
Related
I created a new macOS project in Xcode 11.4 where the language is Swift and user interface is SwiftUI. Without making any changes to the code in the project, the app will disappear from the dock by performing the following steps:
launch the Mac app by running the Xcode project
close the main window of the Mac app
select another running app such as Safari
the original Mac app disappears from the dock with no way to access it
This behavior does not happen if the window of the Mac app is open. I can select other running apps then go back to the original Mac app with no problems.
This behavior is known as Automatic Termination. I find it a misfeature, but Apple considers it a feature.
Your app may not have actually quit. It may just appear to have quit. "Launching" it again will just make it reappear in the Dock. It's also possible that some apps which look like they're still running have actually been terminated by the system. In theory, if you try to switch to them, they will be launched and told to restore their previous state to maintain the illusion that they were running all along. In practice, apps (even Apple's) rarely properly restore things to exactly how they were.
The process list in Activity Monitor is a true reflection for what is and is not actually running. Look there to determine if your app has really been terminated.
A developer is supposed to have to opt-in to Automatic Termination because it requires explicit coding of state restoration. However, Xcode's app project/target templates have it enabled by default. You can remove the NSSupportsAutomaticTermination key from your Info.plist to disable it.
Likewise, you'll presumably want to disable Sudden Termination, too, if you're not prepared to support it. You would remove the NSSupportsSuddenTermination key.
I'm currently adding iCloud support for my app, but i noticed that in the iCloud -> manage storage settings my app's icon is missing. I've added the Icon-Small.png/Icon-Small-50.png plus their #2x versions in the xcode project in the "Resources" folder, then added their names in Info.plist but it still shows white.
What am i doing wrong?
Once you show up in Settings, a little like registering your device for push notifications, there's some caching happening. You should try resetting all settings and installing fresh. Also if it's a physical device, not the simulator, try to delete the app, set the date forward by over a day, install fresh, and it should bypass that cache.
Did you build the app, compile it, and added the icon very later on? This is usually a caché issue. The best way to go around this is to uninstall the app from your device and do a clean build.
How can I install an unsigned application on an iPhone from Xcode? I am using last version of Xcode and the iOS 5 SDK.
You can't.
Apple wants people to sign up with their developer program, and so the only way to install an unsigned app might involve jail breaking, but I don't know enough as I've never jailbroken an iOS device.
Maybe you're not ready to purchase the license yet. That's when you require JailCoder - an easy to use app for tweaking your project and Xcode. Purchase the license and publish your app when you're happy testing with JailCoder.
Note: Here also a jailbroken device is required.
CAUTION! This DOES require a jailbroken iOS Device.
Yes, you CAN!
If you've built it on your own, you can simply use your phone as developer device (if you don't know how, just google it, I don't remember yet).
The trick is to force Xcode to don't try to code sign your app. If you don't, you'll get an error every time, you try to build it.
Go to Terminal and type:
sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/SDKSettings.plist
(You might replace iPhoneOS5.0 with your target SDK)
You'll be asked for your admin password.
Now change the value for the key CODE_SIGNING_REQUIRED to NO.
You are almost done.
Go to your project settings, look for "Code Signing" and set all values to Don't Code Sign.
Set the active scheme to your iPhone instead of iPhone 5.0 Simulator and go to Product → Build For → Build For Archiving
Now go to your Organizer Window, head for your iPhone, go to Applications, press the plus sign at left bottom and choose your build path.
In Xcode4 it's /Users/you/Library/Developer/Xcode/DerivedData/yourApp/Build/Products/Release-iphoneos/ by default.
Select your App binary (it will have a "forbidden" badge, because you're on Mac architecture) and click open.
Wait a few seconds and now your app should be available from your SpringBoard.
It would require jailbreaking, which I don't see why not because my jailbroken iPad doesn't have a virus after probably 300 apps. All the apps from the default repositories are checked and don't have a virus.
I would like to send someone the Xcode simulator version - not the device version - of my iPad app. I have located the .app file in the Finder. Do I just zip it up and send it off or is it more complicated than that?
Thanks,
Doug
UPDATE
Chrisbtoo got the answer on this one however he left of some critical bits for those of you trying this at home:
Path to Xcode simulator (the simulator can be run standalone.):
/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app
Path to app that appears in the home screen of the simulator:
/Users/turner/Library/Application Support/iPhone Simulator/3.2/Applications/{GUID}
It is instructive to watch what happens in the app simulator directory as you build for simulation, delete apps from the simulator desktop and generally use the simulator as an actual device.
Bottom line: This is a viable approach for sharing apps in a "simulated" ad hoc manner without the mind numbing, soul sucking process of true ad hoc app sharing.
Cheers,
Doug
Assuming the other person already has the simulator installed, you can just zip up the stuff under ~/Library/Application Support/iPhone Simulator/3.2/Applications/{GUID} (includes both the .app and any data directories needed) and send it to them - they'll need to unzip it under that same directory. What I've done in the past was to rename the {GUID} part to a more friendly name - the sim will still pick it up.
If they don't already have the simulator, they will need to sign up for a free iphone dev account and download Xcode, etc.
We just put up a little tool that will help you with this. It manages both what you need on the dev side and also the tester.
Here it is
http://blog.placeit.net/ios-app-packager/
It basically creates a little zip that you can pass to the tester and it'll install the app in the right directory and also open it up for the user with the right device selected.
I would think you want to send the entire project folder to the other person- presumably you are expecting them to open it in their XCode- and presumably they have the sdk for the app.
You have to distribute via AdHoc or App Store for beta testing.
Become a developer and then look into how to do this.
You need to have a provisioning profile, and then select the UDID's for the device you want to beta test to.
Go to the iPhone Provisioning Portal
and here is a document with more detail
Curious what practices people have learned before making their final build and submitting to the App Store? Aside from switching from Debug to Release & commenting out calls to NSLog what other basic and/or not so basic things should we be watching out for?
This is a good question and I'd like to restate some of the answers and add a few of my own. I've made this answer Community Wiki, feel free to add to it.
Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning", (b) now navigate around your app to other view controllers and see if everything is working, (c) repeat test for another view controller.
If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
Start your app while on a phone call or when Personal Hotspot is active. Are all the screen layouts correct (the status bar is 40px high instead of 20)? Did the bottom 20px of the view get pushed off the screen or did it resize correctly?
Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?
Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
Run the Clang static analyzer and fix (or at least understand) every warning.
Make sure NSZombiesEnabled is NO in the environment variables (caution: not sure if this is still a problem)
A few things:
I actually recommend not creating a build configuration called "Distribution" as Apple specifies, because I often am creating ad hoc builds for beta testers. I create two build configurations, one called Ad Hoc and one called AppStore, so I'm not confused. The only difference between the two is the presence of the Entitlements.plist file for the Ad Hoc build. This way I can test as closely as possible what I will be submitting to Apple.
Most developers are optimists. That's why we are working weekends to create an app that we just know is going to make us a millionaire. Before submitting though, be a pessimist. Imagine everything that can possibly go wrong, and double check it.
Don't assume anything. Don't assume that that tiny little change you made to the app won't affect anything else. Murphy's Law says that that tiny change will cause your app to crash on all iPod Touches or something. Test, test, test thoroughly between the final code edit and Appstore submission. If you have to make a tiny change, then repeat until it's perfect.
Remember that if the app doesn't crash for 99.9% of your users, then 1 out of every 1,000 downloads will result in a 1-star scathing review.
I use Clang static analyzer, Leaks and Object Allocations during development, but I do an extra run of these tools before submission just in case.
If you don't have an older device, get one, because the 3GS performance is significantly better and you may miss some important performance issues.
Test your app with the following configurations when network or location are applicable:
iPod Touch
iPhone 3G
iPhone 3GS
iPhone in Airplane mode
iPhone with Wi-Fi
iPhone with EDGE
Call the phone while using your app
Instead of switching to Release, I switch to "Distribution". It's a copy of Release, but that's is how I got taught by some Apple doc and iPhoneDeveloperTips.
Important points:
After the final build, but before you rush off to zip up your app, open the bundle using the Finder's Show Package Contents. Due to some bug in the MacOS, which bit me in versions prior to Snow Leopard (and it might still be there), if you zip up too fast (using the Finder's Compress or Archive menu item), some of the resources have yet to be flushed out into the file. When you do a Show Package Contents, the contents get updated. The way you would notice this problem is that the size of your compressed app would be between a fifth to a tenth or less of the expected size. You might think to yourself, "hey, that zip utility really does a great job of compressing", but that's not the case. This problem would occur at this point instead of during testing mainly because you are doing a "clean all" build and all the resources and contents of the app bundle are starting out empty and then being filled by Xcode. And for some reason, even after Xcode is done creating the file, the contents are still not actually there, if you compress, but would be there if you looked at them (sort of a reverse Heisenberg). Beware.
Another area I spend a lot of time on is to make a nice backup of the sources, after I have committed all the latest changes to SVN, made a new branch, and tagged the file. I also like to have my version number match my SVN build/commit number so I always know which SVN version matches my release. I have those two version numbers in my info.plist and can be pulled up by the app user when they hit i for info. For example, a current info.pist includes:
<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>
There are different thoughts on how to use the CFBundleVersion. This is my way. Also useful is the command line utility, agvtool.
Once the app is built, after compressing so you're not actually making any changes to the compressed version, go check the app file and make sure it is signed with the right distribution cert and not your adhoc one. Learning to use the command line utility, codesign, is helpful for this kind of checking and debugging. By making the compressed copy first, you ensure that you're not in any way going to change the final copy that Xcode has handed you and that you will upload to itunesconnect, if all looks well.
Other things to remember are the app icon, the various other icons and graphics you need for the iTunes store, the info.plist, and the fact that when the uploading of the app fails with a cryptic error message, it usually has to do with one of these pieces being missing from the compressed file you are building (those pieces that belong in the app bundle).
Look into this check list document # Github
https://github.com/bapu/AppReleaseCheckList