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.
Related
I need to run a beta test for an iOS 8 app through Apple TestFlight. Is it allowed to upload 2 versions of a beta app for an A/B test? (I would like to switch the app icon and some other things to check what works better for the users.)
Notes on bounty:
Especially interested if there are any experiences with submitting two
similar builds for external testing, as builds have to go through the
(albeit lighter) review process.
I would presume it would be OK, as one can submit freeform notes for
the reviewers and explain the situation—AND because, in any case,
externally tested apps have to go through the normal App Store review
process before going live; so acceptance in external testing wouldn’t
be a free ticket to App Store.
But these are just my assumptions and hence the bounty. Has someone
done this? With negative or positive results? Or both—review processes
are notoriously independent and, at times, arbitrary.
I’m not interested in interpretations of review
guidelines,
but how they are executed in practice.
Or should this all be handled inside the app with some A/B testing
framework? (Which is unfortunately more work than just creating two
bundle IDs… And this wouldn’t help in testing the app icon)
In order to have 2 active builds in test you need 2 apps (different bundle ids), the only choice you have is either through the same account or different accounts. It's easier to handle in the same account, less context switching for management.
We did both successfully without any issue raised from Apple. We did not put any special mentions in the review notes either.
Eventually you end up with more dead projects in your account but its only an issue for you, Apple wont complain.
Why tough
A/B testing can be done in the same build except for some things like you mentioned (app icon). Usually this is handled through surveys tough.
The only advantage of having 2 apps is that all users can test both versions in your A/B test mitigated by their willigness to spend time testing both.
Disadvantages that jumps to mind:
sooner or later you will kill one of those version, potentially loosing some of your beta testers that chose only that version. Mitigated by the fact that you may not need beta testers after you release your appstore version
you wont be able to control who has which version to insure proper distribution and move users from one to the other unless you are ready for lots of hands on communicating with your beta testers.
I have not been able to have multiple versions in TestFlight. If I were to do this I would use a separate provisioning file and iTunes Connect account. There are a few steps to change the provisioning account and the app name so it is unique, but I think that is the only way to get around it. However to use external testers (since internal testers are limited to 25) you will have to go through the review process. Apple might object to having to review the same app twice if they caught it. I would advise rereading the Terms and Conditions, remembering you are submitting for Beta App Review.
As of April 11, 2017, Testflight allows you to you can distribute and test multiple builds at the same time.
https://developer.apple.com/news/?id=04112017a
You can upload multiple builds but you can test only ONE at a time and there is no way to do what you want unless you make a new unique app identifier and upload the same app on the new app identifier APP.
It is possible to upload more than one builds of same version!!! Just change the build number. Example, 'version 1.0, build 1.0', 'version 1.0, build 1.1'. You can see different builds in Test Flight.
I got rejected by the apple review team. The reason was:
2.3 - Apps that do not perform as advertised by the developer will be rejected
We were unable to locate some of the features described in your marketing >materials or release notes. Specifically, your app informs the user to allow >background location, however, there is no setting within your app.
If I go to the device settings and find my apps settings, I see the following:
I've got the following background modes in my plist file:
Apple sends me this screenshot along with the review:
Also if someone could be helpful with telling me the best way to get in touch with Apple. I've tried writing comments to the rejection in the Resolution Center, but I don't hear back.
We cannot tell you why Apple may have rejected your app; we can only guess (at best).
Apple's testers do not always see the same things that you see, as you've submitted an app for production, whereas you're testing it in a development environment. This is why it's important to do Ad-Hoc and/or TestFlight beta testing.
You have to be sure that your app (and all of its functionality) works not only for you in a development environment, but also for others in a sample production environment (ideally on a wide range of devices).
The only way to know what the testers saw is to ask for clarification from them via the Resolution Center, which you say you have already done. The best thing to do is to wait, but if you don't get a response in a reasonable amount of time (say, a week or two), you may want to contact the team.
If you truly believe that this rejection was in error, you can appeal it.
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.
Is there a way to remvoe TestFlight apps from users that have installed them? Also is there a way that TestFlight can bake into the app some sort of password that the users all have to log in with (in case of a lost phone, we don't want our developement apps exposed).
If left untouched, the provisioning of your apps will eventually expire automatically. Even without the native ability to remove applications with TestFlight there is still something of an expiration date on the application.
That would still leave your question of a "baked in password prompt" and removing the application itself physically from the device.
The first part, the app checking for authentication could be solved by implementing a solution with a more robust SDK that happens to have that sort of security-minded approach. As far as I know, and based on TestFLight's feature grid, this exceeds the abilities of their tool.
The second part, removing the application itself from the device, would be accomplished by using a tool that has the ability to use MDM (Mobile Device Management) for device-level control. Specifically you'd want to look for something that can selectively control a single application, rather than having to apply a blanket MDM policy. Again based on knowledge of TestFlight and based on their web page this is also not something TestFlight is capable of.
There are solutions out there that will give you exactly what you are asking about - easy beta testing with the added ability to force the app to check in and re-authenticate as well as the ability to remove applications from the device when you're done testing. If you hit your search engine of choice you can find a few tools that will give you a "yes" to all of your questions here. The list is very short so they're easy to find. :)
If it is at all helpful to you, I am associated with one of those companies, AppBlade, and would be happy to answer questions about this sort of thing. We're at https://AppBlade.com and you're welcome to give us a call or even log into the tool to see how it works for yourself.
Unfortunately you can't delete apps that are already installed on the device via TestFlight, unless you do it on the device itself. As for the password, TestFlight doesn't exactly support that either. You could however put a passcode lock feature in all of the Beta versions of your apps through your code. Sorry thats probably not the answers that you wanted to hear, but TestFlight is still in its early stages.
You are not able to delete apps from a users device, however TestFlight is testing in their 'Area51' an option to force users to update to a new build if there is one available.
If you no longer want testers to access your app you probably could add a new build which justs shows some info screen.
There is a way to expire the builds in the app store connect when you click on build.
Another way if you want to get rid of it as a tested to open the app page and click on stop testing.