How to make small code updates to app store? - ios

im aware this is a small question, but I cannot actually find much answers on it.
I would just like to confirm that even if i want to change just one line of code, I have to make a new archive, upload a new build, make a new submission in Itunes Connect, wait for review, then finally its live?
Or is there a quicker way to make small changes to apps?

No matter how large or small the changes are that you make to your app, you must go through the same complete set of steps to have your update pushed to the App Store.
Apple has no way to know the scope of your changes so the app must be reviewed again each time.
Your best option is to avoid such trivial changes. Fix a bunch of issues in each release or add new features. The best thing of course is to thoroughly test your app before submitting it to Apple. A few extra hours of your own testing will save you days of waiting and it will make your customers happier and it avoids wasting the efforts of the Apple review team.

Related

Testflight How to update a build without trigger a full review?

I am planning to build a prototype iOS application over the course of the next few months--let's say until October 1st--that will need frequent updates for iteration and user testing. After the application is approved for Testflight for the first time, I understand that it will be online for 90 days. I need closer to 140 days.
Firstly, what is the best way to update a build without triggering a few review? My understanding is that updates would not require a review and would take 1-2 hours to become visible, but I'm not sure what process is necessary for this, and what the limitations are. Do I need to update the version number and upload in a specific spot? How do I make sure users can download the new build? Should I delete the old one?
Secondly, how do I extend the time limit beyond the 90 days?
The answers might be related.
My question is similar to this old one, but no-one answered it.
You can make "test builds" available immediately via TestFlight for Internal Testers only.
If you're trying to get it to "outside" testers, then updates will have to go through Apple review.
From experience -- if you include enough information in the Reviewer Notes field, and you are only doing incremental changes, reviews can get done very quickly.
Note that if you are "updating" a test build with a whole new section to your app, yeah, the reviewer will likely put it through its paces.
Side note: I've also found it never hurts to begin your Reviewer Notes with something like "Hi Reviewer!! Hope you're having a great day! This is a minor update for our testers, fixing a couple layout issues, typos, etc."
For your other questions... just update the version number and archive / upload it as normal. It should automatically replace the current TestFlight version (for your testers to download).

How do I replace an old expired iOS app with a new app that I built from the ground up?

I have what I believe to be a pretty unique situation and I can't seem to find a solution online. The problem timeline:
4 years ago I paid a developer to build/upload an app to the iOS App Store for me under my own developer account.
Over the years it became outdated and this April it was kicked out of the App Store
I took some online courses this year and rebuilt the app from the ground up.
I would like to post my rebuilt version to the App Store - completely fresh like it's a brand new app (because it basically is)
A couple more things to consider...
I used Swift vs the original Objective-C that the developer used.
I used UserDefaults instead of what appears to be iCloud. (the dev account seems to be littered with permissions for things I don't intend to use - so advice on how to get rid of all of the weird stuff I don't use would be helpful, too)
I also have a different but similar bundle identifier (it replaces "RandomRuby" with "Random-Ruby") that Apple's App ID registration system seems to not like.
The level content and game play are the same - but I have no idea how to figure out what level the previous users were on. (which I'm ok with if it's ethical to make people start over).
It had In-App purchases (they could purchase consumable "Rubies" to use for hints and there was an "Ad Free" upgrade option. The new app doesn't use ads - it just has consumable "Rubies" for monetization). I have no plan to add ads back in - so I imagine a complete reset would be ok here, too? Again - is that ethical?
With all of this context - my question is...
How do I upload a completely-rebuilt-from-scratch app with the exact same name from the exact same company as an expired app through the iOS Developer system? Is this even possible? I'm having a hard time figuring out where to start. I can't even get past creating an App ID.
To update an existing app in your Apple Developer account you only need to use the same BUNDLE ID (e.g. com.apple.keynote) in your Xcode project and a higher version/build number. Everything else is not relevant.
Your previous iOS APP is bounded with the Apple Developer account when it was submitted. And the APP name is unique, just like anyone else may not create another app named 'Facebook'.
So, if the Apple Developer account was not yours, you are in trouble. You need to ask the previous programmer to transfer the APP to you.
If the Apple Developer account was merely expired, and you can prove that the account belongs to you, I guess you can contact Apple Support for help.

iOS App in "Waiting for review" stage, if I release a new build do I have to repeat the process?

My first iOS app is currently at the "Waiting for Review" stage on iTunes Connect.
Now, we are working on some bug fixes and I need to upload a new build, however, I would like to release the app as soon as possible.
My question is after an app is accepted, how long approximately does it take for Apple to review a new build / version for an app ?
Also see http://appreviewtimes.com to get an idea of current waiting times, based on developers self-reporting on Twitter.
Same as always, 7 to 10 days. Except when you ask for an expedited review, but then you should have a really good reason (and a really popular app ;-).
Any time you change your binary you go back to the end of the review line. The time varies depending on how busy the review team is.
The bulk of the time seems to be in "waiting for review." The actual review process seems to be pretty quick, assuming they don't need more info from you to make their decision.
The process of getting fixes to a rejected build seems to be faster than the original review process.
I would suggest planning on an app review taking 10 days. It might take less time, but that seems to be fairly typical.
94% of all iOS app updates are reviewed within 5 business days at the moment.
You can always check https://developer.apple.com/support/app-store to get the latest info on that.

Can a Bundle ID be reused for a different app within the same iTunes Connect account?

My client is planning to release an iOS app (call it A) on the App Store which only has value for a limited time (say, a few weeks). After that time, they want to release another, basically completely different app (call it B), with functionality that is related to app A, but much more general. B will be built from scratch and will reuse no code at all from A.
They want to release B as an update to A, so as to retain their user base. Technically this should be no problem: we can change name/icon/metadata, as long as we keep the Bundle ID the same. But will this be a problem with the review process? Could Apple decide that it would be confusing for the user to release a completely different app as an update to an existing one?
So a different way of putting my question would be: can we freely reuse a Bundle ID for a different app within the same account?
Does anyone have experience with this?
What you want to do is absolutely acceptable. I don't see any reason why Apple would reject your app.
I personally recently updated an app with a new icon and a new name.
Granted, I kept most of the features from the previous version, but I really don't see Apple rejecting an update based on "it's too different from the previous version". Also, you often see notes in updates saying "rewritten from scratch", so this is also perfectly valid.
Technically you can do this, and lack of code re-use is irrelevant.
I have written and submitted apps that have have had their codebase completely replaced over their lifetime.
I've also changed an app's icons and name, so all the component parts are definitely OK to do.
You cannot reuse a bundle ID. Your best option is to just update the app. The review process accounts for major changes like this, so it will most likely be a longer review time.

Know whether user downloaded iOS app for free or paid?

I am switching my iOS app which is already on the app store from paid to free. I want to know which users have paid for the app, so I can treat them differently (like not showing them additional ads). As far as I know, there's no way to get which version of the app users originally downloaded.
One thing I thought of is this. I can release an update at the same time the app goes free. Everyone who launches the game for the first time who has the update gets marked with a "Free Download" flag. The issue here is what if someone paid for the app, then didn't launch it, then updated their app. That means I will treat them like a free user even though they have paid. Thanks!
There's no way to do this with 100% accuracy without releasing a new app.
If you do use a flag of some sort, save the flag in the keychain and/or iCloud so that it will have a better chance of persisting across uninstall/reinstalls and from device to device (if you use iCloud).
Your best bet though is probably to release a new lite version of the app. It can be a pain to maintain two versions, but at least you know for sure who's paid and who hasn't.
I somewhat accomplish this with a server-side script. On initial app launch, I grab data from my server to determine if this is a paid or free install and then save this info in iCloud. It works relatively well, but it does have a drawback; a small percentage of the time the query fails. If it fails, I just set the app as being paid so as not to screw anyone over. This screws me over a bit, but I take the hit for the convenience of not having to update whenever I want to switch paid/free.
You cannot show updates or advertisement for the customers separately who bought the app for free or by paying money. Whenever you changed your paid app to free, the customers can download the application for free now.

Resources