Many iOS developers received the following message recently. Does it has any impact on React Native?
Your app, extension, and/or linked framework appears to contain code
designed explicitly with the capability to change your app’s behavior
or functionality after App Review approval, which is not in compliance
with section 3.3.2 of the Apple Developer Program License Agreement
and App Store Review Guideline 2.5.2. This code, combined with a
remote resource, can facilitate significant changes to your app’s
behavior compared to when it was initially reviewed for the App Store.
While you may not be using this functionality currently, it has the
potential to load private frameworks, private methods, and enable
future feature changes. This includes any code which passes arbitrary
parameters to dynamic methods such as dlopen(), dlsym(),
respondsToSelector:, performSelector:,
method_exchangeImplementations(), and running remote scripts in order
to change app behavior or call SPI, based on the contents of the
downloaded script. Even if the remote resource is not intentionally
malicious, it could easily be hijacked via a Man In The Middle (MiTM)
attack, which can pose a serious security vulnerability to users of
your app. Please perform an in-depth review of your app and remove any
code, frameworks, or SDKs that fall in line with the functionality
described above before submitting the next update for your app for
review.
The recent action by Apple seems to target frameworks that are about to modify native code bundles on the fly. If you are using this kind of library in your RN project then you might get effected. But if you are using a library like Code Push which lets you modify js bundle, you are not expected to get effected. There is a HN thread about it. You can search for Microsoft keyword to read about. You can also read this.
Related
I want my app to make urgent security updates without going through Apple's review process. I am not trying to do this for all my updates, or circumvent Apple's reasonable review requirements. All it would have to do is push a .swift file to the client, which would be accessed somewhere in the app.
I definitely know there is a way to do it in JavaScript, as I already made a mechanism of the same type in a React Native. I used this approach, but I don't think there is an equivalent for iOS from what I've heard.
There definitely is a solution, as I've heard many devs doing this (for less, um... valid reasons) but I can't find it.
You cannot do this, for both technical and policy reasons. Apple expressly forbids you from delivering new code to your apps's outside of the app store process.
The other part of it is that your apps run compiled object code, not source code. Aside from the iPad Swift playgrounds app, there is no Swift compiler on the user's devices.
Javascript is a horse of a different color. That's an interpreted language, and is designed to be delivered and run dynamically.
I received the below email shortly after I submit my app to the AppStore from XCode Organizer. My app contains the framework in this GitHub (https://github.com/wujianguo/iOSAppsInfo), I use it to create shortcuts to the rest of the users installed applications, and ONLY for that purpose.
Is there a different way of getting a list of all installed apps so I can create shortcuts or will all methods be instantly rejected as below?
Dear developer,
We have discovered one or more issues with your recent delivery "shortcut-app". To process your delivery, the following issues must be corrected:
Non-public API usage:
The app references non-public selectors in Xxxx xxxx: _applicationIconImageForBundleIdentifier:format:scale:, allInstalledApplications, appTags, applicationProxyForIdentifier:, localizedShortName, openApplicationWithBundleID:
If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed.
If you think this message was sent in error and that you have only used Apple-published APIs in accordance with the guidelines, send the app's nine-digit Apple ID, along with detailed information about why you believe the above APIs were incorrectly flagged, to appreview#apple.com. For further information, visit the Technical Support Information page.
Once these issues have been corrected, you can then redeliver the corrected binary.
Regards,
The App Store team
This library uses private API which you cannot use especially when you submit the app to apple, as they will reject it like this.
I am not aware of another way to get installed apps, but in order for apple to accept uploading the app, you must stop using this library, specially this method.
I am trying to find device lock state as UIApplicationState gives the wrong state when Lock the device, it gives UIApplicationStateActive for few second.
I found one solution using Darwin notifications for notification "com.apple.springboard.lockcomplete".
Is it the correct way to get Lock state? Does Apple allow this?
No Apple won't allow to use "com.apple.springboard.lockcomplete".My application get rejected due to this.
The answer is... it depends.
Using non-public API is not permitted, and these Darwin notifications are not publicly documented. So the official answer is no, you are not allowed to use this notification in a production code. Otherwise, you risk getting this unpleasant email from Apple:
Your app uses or references the following non-public APIs:
com.apple.springboard.lockcomplete
On the other hand, I've used that very notification for 4 years till I got a rejection from the App Store for one of my apps. Another app of mine still uses it without problems. So if you really need it and you think it's worth the risk, you may give it a try.
Based on our experience, your app WILL be rejected for use of com.apple.springboard.lockcomplete with the following notification:
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:
com.apple.springboard.lockcomplete
The use of non-public APIs is not permitted on the App Store because
it can lead to a poor user experience should these APIs change.
Continuing to use or conceal non-public APIs in future submissions of
this app may result in the termination of your Apple Developer
account, as well as removal of all associated apps from the App Store.
Next Steps
If you are using third-party libraries, please update to the most
recent version of those libraries. If you do not have access to the
libraries' source, you may be able to search the compiled binary using
the "strings" or "otool" command line tools. The "strings" tool can
output a list of the methods that the library calls and "otool -ov"
will output the Objective-C class structures and their defined
methods. These tools can help you narrow down where the problematic
code resides. You could also use the "nm" tool to verify if any
third-party libraries are calling these APIs.
Resources
If there are no alternatives for providing the functionality your app
requires, you can file an enhancement request.
Apple won't allow this.Here is there comments for this
"The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.
Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store."
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 released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.