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.
Related
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 have an open source iOS project with public sources on github. I have published the app on the App Store using my developer account.
Is there a way for me to prove to the user that the published app in fact has been compiled from the sources on github?
EDIT
To clarify: I am in search for a mathematical (or cryptographic, if you like) proof that the app binary originates in a publicly available source code, rather than a sort of disclaimer. A disclaimer can claim anything but does not prove anything.
E.g. by code signing the app package I prove to apple that the creator of the app and the developer registered with apple are one and the same person. My question is whether there exists a similar mechanism to prove to the user that the origin of the binary and the public source are identical.
I think I've stumbled upon a hard problem. It is much more general than iOS. It is hard to prove that the origin of a certain binary is a given source code at least because the binary you'll get depends on so many details:
compiler version
os patches
compiler flags
exact library versions and their compiler settings
values of environment variables at compile time etc.
The proof would need to take all that into account somehow.
Maybe the developer could make a video of how he pulls the repo, then compiles, then calculates a hash sum of the binary. then he could publish that video. But again, the video could have been tampered with. Or the compiler could be compromised.
So apparently we have to trust the developer. This "trust in the developer" attitude seems to be the norm. With security critical open source projects the developer would sign the binary. After downloading the binary I would verify the signature before running the code. In the case of an iOS App, the App Store takes care of all that. As a developer I have to code sign the binary. Apple would verify that signature before putting the app into the app store.
As a result, if you put an App in the App Store, I know that Apple knows who you are. So it is easier for me to trust in you.
TL;DR : A proof would be hard, but you can make it easier to trust.
For iOS there are additional complications. Part of submitting your app is codesigning it, and the codesigning process involves changing the Mach-O header, the load commands, and the LINKEDIT segment.
You could probably increase trust (but still not prove) by submitting the code-hashes in the code-signed code-directory structure; BUT the app in AppStore is re-signed by Apple and thus some of the code-hashes will have changed no matter what you do.
One way to do that is by showing the information in iOS settings bundle. I've seen couple of application implementing iOS settings bundle and showing acknowledgements/attributions over there. Other way would be showing that info inside your itself but I wouldn't recommend that.
I have an app that sends logs to Keen IO for logging and analysis purposes. The code that sends logs to Keen IO is guarded by preprocessor macros, and hence it never sends any logs when I’m running it on the simulator or my own phone while development.
What I generally follow is this — After the app is (almost) done, I release an ad-hoc version and give it to some testers who use it for a few days and test it. However, since it is also a “release” version, the app sends analysis data. This data usually pollutes my other data that was supposed to come from my real users!
I want to programmatically know inside the app if it is an ad-hoc release version or AppStore release version, so I can handle those two conditions. Is there a way to do this?
The only way I can think of is have another preprocessor macro AD_HOC that tells that its a test version. But it can happen that I forget to remove the macro while submitting to the AppStore. Its not gonna help if that happens.
I use such a macro for a very similar reason. I build the adhoc version using the release building setting and the app store version using the distribution build setting. In that way I avoid forgetting to set the #define to the right value.
I'd like to sign my iOS apps on a Linux box (Debian 5 if it matters). Does anyone know if this is possible? (Let's not get into why I'd want to do this since it's specific to my environment.)
I see source code to codesign on Apple's site but before I get into the weeds pulling it over and trying to build it myself, I wondered if anyone knows of an existing port.
I'd heard that codesign is not really OSX-specific and may exist on other OS's but there's always a chance Apple has tweaked it to their own needs. I wonder if an app signed by something other than Apple's codesign will run on an iOS device.
If it matters, the signed apps are meant for enterprise users and will not go in the iTunes App Store.
Saurik wrote a codesigning utility called ldid, I think for OS X and iOS. It also might be available for Linux though.
Check out JTool.
Code signing is considered to be the second most useful feature of JTool. With iOS security revolving around code signatures and entitlements, it's important to have a way to quickly determine what given entitlements a binary possesses and how it is signed. OS X has codesign(1), but I find it crude (at best) - and what more there's no port to iOS, where it's really necessary.
My application is in the Apple App Store but when downloaded it crashes after the splash screen.
I thought the week long approval process was to ensure the quality of the app.
Version 1.0 of my app does run but I hear there is no way to roll it back. For now I have changed the availability date to the future so that people do not download it. When will it be taken out of the search results?
Thanks.
The approval process is not for QA testing. (Of course, they will reject an app if it crashes while testing they are other for things, such as violation of various SDK rules, HIG guidelines, etc.) A developer has to test and QA your apps themselves on the OS versions and the iOS device types for which they submit the app as appropriate for, and under stress conditions as well. A developer also needs to make very certain that the build they submit is identical (except for certificate signing) to the builds they have tested. (It is a common mistake to have different Build Settings or source files selected between the Release and Distribution builds.)
Check to see if a bad preference setting is the culprit.
Or if it worked only for you, then it may be the lack of a preference setting. You may have created a good preference before the bug was introduced.
Was taken out of search results by the end of the day.