When an app is undergoing the app store approval process, do the people at Apple check the warnings in your project, or do they only check for errors?
e.g. I have this warning on a lot of my NIB files:
Unsupported Configuration: Title set but using a system Identifier (These attributes are mutually exclusive; the Title will be ignored)
Will this be a reason for Apple to reject my app for the app store?
Apple won't check for warnings in your project, because they can't. They don't get the source code to your app, only the compiled binary and supporting files. So long as you follow the rules, you should be fine.
As for the specifics of your question: I very much doubt it, but nevertheless, you should definitely aim for a project which compiles without warnings, just as a general programming practice.
Related
I'm looking for an open source for antitampering and Code obfuscation tool for my iOS project. Some library like Proguard in Android.
I found iXGuard and Dexprotector are paid tools. I'm looking for some open source tool.
Any help will be appreciated.
Xcode already does most of the obfuscation part
Find the points below:
Code tampering and obfuscation are hardly related terms because RELEASE native builds from Xcode destroy names of variables,
functions, etc So I would hardly bother with obfuscation - you just
do not need it.
Apple encrypts the code of the applications submitted to the App Store and restricts access to the machine code of the apps after
download to prevent easy static analysis of the application.
And what use case do you mean when you refer to anti-tampering? Do you mean the release of the same app with different resources (images + brand name) to the official app store? - I would hardly bother with such attempts.
And be prepared for any App Store rejection if you are doing any extra code obfuscation by using paid or any other third-party tools. Apple rejects most of the obfuscated things done through these tools. Apple rejection message looks like this:
3 Performance: Accurate Metadata Guideline 2.3.1 - Performance We discovered that your app contains obfuscated code, selector mangling, or features meant to subvert the App Review process by changing this app's concept after approval to the App Store.
https://developer.apple.com/forums/thread/113211
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
https://mentormate.com/blog/security-in-ios-protecting-ipa-file-content/
I have searched for a library that helps me to obfuscate the code and I've found this one:
https://github.com/rockbruno/swiftshield
I know that Swift libraries can be statically linked, but I'd heard that linking in Swift would cause Apple's private API detectors to prevent it from going into the App Store? Is this true?
Found a link on an Apple Forum; hopefully it helps you, I haven't yet submitted anything to the AppStore yet.
But overall, seems like it's possibly more trouble than it's worth. If you get denied, you're possibly then going to spend time rebuilding/reworking.
Seems to be one point brought up, is to ensure you've added all files needed to compile your App, in your submission.
Link below:
https://forums.developer.apple.com/thread/94488
As of Xcode 9 beta 4, Xcode natively supports static libraries with Swift sources. but You have to use dynamic lib
Here is how Apple describes their dynamic framework:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Source: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
My iOS app has gone through multiple releases. I just added another feature (playing audio files using facebook audio360 tbe format), and the app got rejected with the wording:
From Apple
2. 3 Performance: Accurate Metadata Guideline 2.3.1 - Performance
We discovered that your app contains hidden features. Specifically, It
would be appropriate to remove all code obfuscation and selector
mangling from this app before resubmitting for review.
The next submission of this app may require a longer review time.
Next Steps
Review the Performance section of the App Store Review Guidelines.
Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer
Program.
Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the
review process may result in the termination of your Apple Developer
Program account. Review the Terms & Conditions of the Apple Developer
Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review
Guidelines, you may submit an appeal. Alternatively, you may provide
additional details about your app by replying directly to this
message.
I am not performing "code obfuscation and selector mangling", has submitted an appeal, which was also rejected pointing to the same guideline.
I am using objective-c with some swift, Xcode 9, Product -> Archive -> Submit to App Store... Is it doing some obfuscation that I could turn off?
Perhaps your audio playing feature is using a 3rd party framework which does use code obfuscation?
In any case, you can use the /usr/bin/nm tool for outputting the symbols within your raw executable and see if any of those look "mangled" in any way.
It's most probably a 3'rd party library that does that.
I used Hopper to get to know the library.
First, unzip the ipa and get the app file.
Second, Drag it to Hopper and start scanning it.
Third, search for the mangled selectors.
I am using TestFlight - must I remove all the source code from my solution or is it okay just to comment out any calls to TestFlight before submitting to App Store?
The testflight library adds quite a bit of weight to your app, and it would seem sensible to remove it from your app store builds if you are not using it. Commenting out your calls is also rather cumbersome.
You can use a different build configuration which uses preprocessor definitions to prevent your testflight calls unless you have built for beta, this configuration can also exclude the test flight library from non-beta builds.
This also means that your simulator runs don't call testflight either, which is usually a good thing.
There is a good explanation of the process here which also refers this other question here on Stack Overflow.
I'm about to submit my apple iOS app for the first time,
and have a few general questions regarding submission.
1) Can I choose the platform specifically, like iPad or iPhone, but not both?
2) My app runs well in general, but keeps receiving a warning at a certain point of the app, and often crashes. How strict is Apple with that, and could that be a cause of rejection?
3) What is the uploading process like? Do I get to manually upload all the classes and resources and frameworks, or is there a single magical way that uploads everything for me?
4) Is it required to have a website that supports the app? or can I just leave it blank?
*added:
5) if it gets rejected once, can I re-apply with the same app?
1) It is a project setting. It will require some extra work on your part if you plan on releasing both an iPhone and iPad version (multiple xibs, etc).
2) Run your app through instruments and try to reduce memory leaks. Also, if you are dealing with large images in your app, do it sparingly and be sure to release everything properly (one of the main reasons for app crashes in my experience).
3) You'll build the app for release and have it signed with your developer certificate (Xcode will do this for you once you have it all setup). Then you'll run through the web interface filling out app information, uploading screenshots, and finally the zipped .app package which you built earlier. Make sure you don't have any spaces in the zip filename, and don't change your .app name.
4) You don't need a website for support, but it if is required just link to one of your personal sites (twitter, etc).
5) You can resubmit to your hearts content until Apple finally approves your app. But, you USUALLY won't have an issue with rejection unless you are doing something Apple has explicitly banned or your app is in such a bad state that the testers can't even test it.
5) Yes you can resubmit, as many times as you want. You don't even have to increase the version number (except maybe for your own internal accounting). It depends on the cause of rejection though - if it's a bug you fixed, it's one thing; if it's a rejection because of policy violation, resubmission won't help you much.
Before your app can be reviewed, the following issues must be corrected:
Invalid Binary Architecture - iOS 3.0 introduced support for multiple binary architectures. If your binary is built for multiple architectures, your Info.plist must have a MinimumOSVersion key with a value of at least 3.0. Additionally, if your app is intended to support earlier iPhone and iPod touch models, your app must contain at least an armv6 binary; "thin" armv7-only binaries will not be accepted unless the armv7 required device capability is also present in the Info.plist UIRequiredDeviceCapabilities key or the MinimumOSVersion key has a value of 4.3 or higher.
For more information, see Technical Q&A QA1707 at: http://developer.apple.com/iphone/library/qa/qa2010/qa1707.html.
Once these issues have been corrected, go to the Version Details page and click Ready to Upload Binary. Continue through the submission process until the app status is Waiting for Upload and then use Application Loader to upload the corrected binary.
1) You do it with your app.
2) If it crashes when they are testing it it will be rejected.
3) You build the app, zip it, and upload.
4) You have to put in some info. It should probably exist.