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.
Related
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 have an application that uses HealthKit and Swift in it, everything compiles and runs fine when I test it from Xcode on a simulator or a device. I tested, debugged it, and submitted it to the iTunes store. When the application was approved I downloaded the new version from the store and it crashed right away. This was extremely puzzling as I have never had this issue before. I look at the diagnostic and usage logs on my phone and the crash report for the application says this:
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Reference from: /path/to/my/app
Reason: no suitable image found.
Did find: /path/to/my/app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x100174000, size=0x0194000 segment=__TEXT in Segment::map()
Has anyone seen anything like this or know how to deal with it?
Thank you
EDIT:
The crashing issue magically fixed itself on the morning of October 4th, which tells me that this was an Apple issue. I have been emailing iTunes Connect Support, but they have not said one way or another what happened. I also opened a technical ticket without even a response back from Apple. This is pretty disappointing, not just for the fact that Apple is not being transparent about the issue, but also it makes me feel like I have no course of action later on down the road if this ever were to happen again.
Simply do the following two steps:
1) Delete the App from the device (or simulator)
2) Clean your workspace (CMD+SHIFT+K or via menu Product->Clean)
3) Build and run your app again.
Magically helps every time with all that startup / deploy stuff...
I also often get something like "application not found on device" or signing problems etc. Minutes before everything worked well.
This appears to possibly be a code signing issue on Apple's part, and the issue seems affect apps with embedded frameworks (including non-Swift apps). There are multiple accounts of developers being affected (myself included) who had only submitted an update, without changing any build settings. Some high profile apps appear to have been affected and tickets have been filed with Apple, but there has been no official response from them at this time.
EDIT: This has been confirmed.
Edit:
The app was rejected, after making this change, for the same reason, however, I am confident that the problem has to do with a missing architecture version in the libswiftCore.
I am going to post this as the provisional answer.
Xcode 6 Standard architectures exclude armv7s
Notice how the error says: Did find: /path/to/my/app/Frameworks/libswiftCore.dylib
So it did find the lib but it also says: Reason: no suitable image found.
After running lipo against the archived build it didn't contain armv7s in the swift library, or in the app binary. I manually added it per the link above and the binary now contains support for armv7s though the swift library still did not. My app is in expedited review so I should get feedback farily quick. I will follow up when that does happen.
I had the exact same problem with one of my app version updates (FunKeyBoard 1.1).
After doing some research, looks like it was an Apple side issue for many apps updated on October 3rd. Apple fixed the issue on October 4th by releasing an update, same version number, without needing any fix/re-upload from the app developer.
Obviously an Apple side issue, but I'm surprised Apple is very quiet about it. Many developers, including myself, got angry emails from users, and poor app reviews, as a result.
This error typically occurs when signing Swift apps with certificates that lack "OU" (Organizational Unit). All certificates created after the release of iOS 8 should have this. The simple solution is to create a new certificate to sign with.
For more details, see the official Apple comment here: https://developer.apple.com/library/ios/qa/qa1886/_index.html
It seems that my on the iTunes store is now downloading and opening as expected. From what I have been reading in the Apple Developer Forums, other apps are also working now too. I have not received any word from Apple on why this happened or what caused this. I opened up a technical support ticket with them and I also contacted iTunes Connect support and there is no
explanation or any information on this issue being resolved. This is pretty poor customer service on their part.
I had the same problem. I removed support for arm64 and added armv7s and now apple review team approve the app.
I recently recovered from not being able to test on my device in Xcode. After much headache, it turned out that I only needed to uninstall/reinstall iTunes, but I'd certainly rather not do so frequently.
(See: prior thread)
The troubles seemed to begin after I built and ran some sample projects which obviously did not have my App id, etc. Is this always the case? Should I live in fear of compiling other projects that I haven't previously associated with my device and/or developer profile?
I'm not exactly sure if the App id/bundle/provisioning/keychain/whatever needs to be done per test ad hoc App or if it only matters that your device is provisioned and your plist matches what Apple has when you go to upload to the iTunes store.
I've run many samples on my device through Xcode and never had any issues. There's certainly no reason why this should happen.
It's hard to say "No, you shouldn't be worried" without knowing what the issue is, but it's not intended to break in this way, and it doesn't for most of us!
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
I have submitted the binary file of my application to apple on appstore.
But I didn't configure the APP ID. Does it will affect my application for apple submission?
Should I do a developer reject and if I do that Can I upload the new binary ..?
Please reply me as soon as possible I don't want my application to get rejected by apple..
Rejecting your own app is a rite of passage, it won't hurt future submissions. Reject it, fix it, resubmit it.
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.
This Solution will surely help you to upload your App on iTunes.
When you say you didn't configure the App ID, do you mean the Bundle Identifier? You can replace the binary once you reject it. Just note that a developer reject will move your app to the back of the queue