Hopefully a easy(-ish) one, but I'm just wondering if it's possible to update an ad-hoc over-the-air installed iOS app (deployed using the standard $99 developer license), hence ensuring that any data stored within the app's document sandbox is still available.
Additionally if iOS 4.x file protection is used (i.e.: the NSFileProtectionComplete encrypt attribute is set on the files, etc.) will an updated app still be able to read the files?
Whilst there are some existing questions that touch on this (such as Updating enterprise iOS apps while retaining some files of the current app bundle), these don't answer this specific query and (potentially) pre-date the newer style of ad-hoc distribution.
You can definitely update an ad hoc over-the-air-installed iOS app and retain the current app data -- it appears to work identically to normal update installation.
Because it works the same way as a normal update, file protection should work the same as well, though I don't have first-hand experience.
Related
My app contains code that must modify the DB in the documents directory on update of the app (because the structure of the DB has changed between versions).
The loading of the new version of the app to a phone via xcode works fine, and runs the code correctly. However I'm concerned that this may not exactly mirror what happens when updating via the app store on the phone.
In order to properly test that this code runs correctly when a user updates their app through the app store, I gather it used to be possible to load the app via an ad hoc distribution, which would install it as if it were an update from the app store. The (rather old) instructions for that are here:
https://developer.apple.com/library/archive/technotes/tn2285/_index.html
I attempted this, by exporting the ad hoc .ipa file and dragging onto the device in ITunes, only for it to tell me the app is already installed. The .ipa file contains the updated app and it has a higher version number than the one installed on the device.
Do I need to do this another way? Or is loading the app via xcode sufficient to emulate what the user's phone will do when updating the app?
Thanks
I hash my iOS executable at launch to verify its integrity, and have had no problems doing so until TestFlight -- which appears to modify the executable as well as install it in some funky (undocumented?) way.
Even more concerning is I get multiple hash values, which appear to vary by device or iOS version or carrier or something. I don't own enough devices to be certain. But none of the hashes match the one I compute prior to uploading to TestFlight.
So I have two questions: (1) What is TestFlight doing to my executable, and is the process documented somewhere? And (2) Does the final app store release pull the same shennanigan, or something similar, or does it leave my executable unmodified from when I uploaded it?
That's what code signing is for.
Code signing your app assures users that it is from a known source and
the app hasn’t been modified since it was last signed.
Source: https://developer.apple.com/support/code-signing/
It seems like Apple encrypts your app. While this post is about App Store submission, could be the same for Test Flight (not sure about this).
See: https://stackoverflow.com/a/5784332/2019384
Also it's not recommended to verify your apps integrity by yourself, as you'll run in such issues. Besides iOS already does this for you:
Apple does not provide any supported way for you to check your app’s
integrity. iOS already does that by default.
Source: https://forums.developer.apple.com/thread/52801
In addition to d4rk's answer, if you're using Swift, Apple compiles in appropriate bits to optimize your app for each device.
I'm working on an update for one of my games. I had a version that I downloaded from the app store on my device, and I pressed Run in xcode... The app got updated, but I had a little scare when I noticed that the game's stats all disappeared.
Now, after looking over my code, my only theory that makes any sense is that identifierForVendor is different. I use this as part of the key to encrypt my game's data (to make it impossible to just copy data between users). If it changes, it makes perfect sense that the data is lost.
So before submitting my update, I wanted to verify that this is the case - does identifierForVendor change between development versions and distribution versions?
Thanks!
Found the answer - in the documentation, of all places :)
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIDevice_Class/index.html#//apple_ref/occ/instp/UIDevice/identifierForVendor
Normally, the vendor is determined by data provided by the App Store. If the app was not installed from the app store (such as enterprise apps and apps still in development), then a vendor identifier is calculated based on the app’s bundle ID. The bundle ID is assumed to be in reverse-DNS format.
So the answer is "yes".
I'm developing application for in-house distribution (so there can't be rejection from Apple).
As I'll distribute my app using Enterprise distribution, I'm missing one of key features of AppStore - Auto/Manual updates. (I know, that I can show popup users to update application)
Also I know, that application can download dynamic framework with code, and also can download bundle with resources.
So my question: How can I download storyboard (compiled to nib) from remote host, and load it into project?
Or is there anyway to make something like Sparkle.framework on OSX, which will update all the bundle of my app?
You can't update it silently and automatically but you can ditribuite with TestFlight or similar services. Crashlytics present an alert to update if a new version is available (and then use itms-services) .
You can even use itms-services yourself and build your own distribution system if you like.
Take a look at Artisan. They allow you to build portions of your app on their web interface and dynamically swap out views and workflow. It is generally used for A/B testing but could be used for your purposes too. This way you could change significant elements of your app without needing people to update anything. You can even setup different views for different groups of people, and again, all after application launch.
It is also free for <10,000 users, which I am assuming would not be an issue for an enterprise application.
When submitting an update to an app to the app store (via iTunes Connect?), is the update necessarily a whole binary? Can an update come in the form of a patch? If a second version of an app shares a lot of assets and logic from the previous version, does all that logic/resources get reinstalled wholly regardless?
There are no patches. It's installed as an entire read-only bundle. The old bundle is replaced with the new bundle.
Application data is retained (ie. documents folder, NSUserDefaults).
As everyone said before me Apple does not supply a way to hot-patch native apps, moreover it has a clear restriction - "No remote code injection".
The only thing I can add is that hybrid apps which use a javascript platform allow you to remotely replace the JS file, so you can actually change functionality remotely.(without having to release a new version) other solutions I have seen are in the gray area and allow you to run Lua Script remotely to change app functionality.
We # Rollout.io have a different approach, we allow you to hot-patch production apps without code injection on native applications, you can read more on how the tech works here
Rollout is meant to help mobile developers solve production quality issues, hot-patching production apps, debugging production env, adding/removing analytics, etc.
Disclosure: I'm from the Rollout.io team.
iOS 6 now supports delta app updates. This is awesome, and makes Real Racing 3 (a 1.1GB app) update in about 30 seconds instead of 20 minutes!
https://developer.apple.com/library/ios/#qa/qa1779/_index.html
Q: How can I reduce the downloaded size of my app update for users
that already have the previous version installed?
A: Starting with iOS 6, the app store will automatically produce an
update package for all new versions of apps submitted to the store.
This package is optimized for updating an app from one version to
another, and contains files that have changed between the prior
version of an app and the new version of the app, excluding files that
have not changed.
When used optimally, an update package is significantly smaller to
download than the full package of the app and the update will install
more quickly. Also, in many cases, this mechanism allows updates to
large apps to be downloadable over cellular networks where app
downloads are subject to a size limit.
In addition to new content, the update package contains instructions
on how to transform the prior version of the app into the new version
of the app. New files will be added, modified files will be replaced
with their updated counterpart, and deleted files will be removed as
part of this transformation. As far as the developer and user are
concerned, this process is entirely transparent and the resulting
updated app will be indistinguishable from a full download of the
corresponding updated version of their app.
Further instructions for developers available at the link above.