this is my first ios app. am working on a version 1 that i'm planning on giving to few of my customers. customers will get it from app store. in future, if i have new version that i'd like to notify current users, is there anything that I have to put in version 1?
thanks.
Yes, you will need to put something in version 1 in order to do this if you want some kind of notification in the app itself. You can go about it a few different routes depending on how complex you want it to be:
You could add push notifications to your app, so that you can send a push notification to your users letting them know an upgrade is available. You would probably only want to do this if you used the push notifications for other purposes as well, as users probably wouldn't want to allow push notifications for an app to only inform them of app updates.
You could have your app check with your server upon app launch to see if there's an update available. You could simply have a file on your server that the app checks which can contain the version number of the most up to date app you have available. If the server reports a newer version than the version reported by the app, it can display a message, which could also be contained on your server to be configurable. This would be pretty simple to implement, and could possibly contain other configuration information for your app. You could also choose when to show the prompt, in case you don't want to bug users for some updates but do for others. This would be good to do if you might release an update that requires users upgrade in order to continue to have it work with a backend server.
You can also get your app to check directly with Apple to see if a newer version of the app is available on the app store. You should be able to find a resource that will instruct you how to do this. Going this route, as soon as an update is available it will start bugging users to upgrade, so you may not want to do this if you only want to push some updates on your users but not others.
You can do nothing. On iOS 7 by default app updates get automatically installed, and even if they have that disabled, the user can see what app updates are available in their app store app. This is what most apps do, aka they don't bug the user every time an update is available. And if somebody isn't updating their apps anyway, your prompt won't necessarily encourage them to do it either.
It's similar to the message appearing in Chrome when a new version is available - something like "Chrome has just got better".
Presuming that you have a server side counterpart, my approach would be the following:
store the latest version number of your app somewhere on the server (database, configuration file, etc)
implement an API at server side that, upon an app version provided as parameter, returns true if an update is available
in your app, read the current app version (see this SO answer)
call the remote API mentioned in (2), and act accordingly if the return value is true
Note however that appstore notifies the user when an update is available - but that doesn't happen in-app
Incrementing the app version is enough for App Store notification as explained in
iPhone app Update Vs new version
Related
I need to push out an app-update, that sets the app (app-A) up for being migrated and retired. The new app that users will migrate to (app-B, different bundleId) is ready, so I would prefer it, if there are no new users to app-A.
Concretely: Can I offer app-updates to app-A, while preventing users from installing it new?
I have seen this not-encouraging post from 2017: iOS App Store - retiring an app - Can I hide the app from new users while making updates available to all existing users - it's been a while, so things are looking better presently.
Creativity is allright here, but obviously any updates to app-A needs to pass review, so it can't just be an empty shell that points to app-B.
After being in contact with Apple support about this, it is clear that it is not possible. The following is copied verbatim from Apple support reply:
Currently, there is no feature that could allow you to prevent potencial users to download the app, while it is still available in the App Store. To prevent users from downloading app, you will need to remove it from the App Store.
The "solution" is to keep the A app around - and only providing the move-to-B functionality - until we either see no activity on it, or don't care anymore.
Assuming you created an app that users have downloaded that is just awful and you neither want to fix it nor have anyone continue to use it so that it won't tarnish your brand, is there a way to end its life on user's iOS devices?
Curious if there is some store setting to force it to work with earlier versions of iOS and invalidates the current app, or code that would force an update that says the app is no longer available.
As many have confirmed, there is no way to remove an application from someone's device. For these cases though, many companies have servers that the application sends a request to on launch, that returns either a need to update the app, a message, or to tell the user the app has been discontinued and that the app cannot be used anymore, stopping them from using the app from there on.
The last use case might be useful to you, but of course this is a proactive solution, not a reactive one.
I am creating a weather app and want to give local warnings to people through an app. I want to be able to give up to date warnings, but I am wondering: does updating information in Xcode get automatically pushed to the devices or will it need an update every time I put new information in?
If I understand your question correctly - you have an app, which warns people about some unexpected weather conditions?
You basically have two options:
Do a code push to your app every time you do a change. This is not supported by default in Swift and Xcode, and can only be done via some third-party integration or framework (e.g. React Native), and is generally a hard thing to implement.
Setup a back-end server and link it with your app, so the new information is downloaded from this back-end server dynamically.
The only suitable and easy thing to do for your use case seems to be option 2.
i have an ionic android mobile app which connects to a ruby on rails api server
and this app uses postgresql as database server.
whenever i create a new feature i deploy both, the api and the new app to the app store and bump the respective versions of api and the app, which have their own version numbering sequence.
The api is deployed to the server but app's on users devices are not frequently updated so below 2 cases arise for me
Case 1 : New columns additions
Issue happens for a release when for e.g i have few new columns added to certain tables in db to capture additional info for which respective text fields have also been added to the app's UI.
Here users of the newer version of app will work as expected (send those 2 info to columns) but the older versions will not be sending those 2 field values
Case 2: Columns deleted
for instance i am re-architecting the app in a major way and have to normalized the database as it was inefficient earlier which even leads to breaking of tables etc or deletion of a couple of columns.
Here the older versions of app would simply crash or fail to work.
i feel every business app i build will have this same scenario to manage and it should be common issue to all
I am in the process of writing some custom logic where the app would check when connected to api server for a "update flag" and if the app's version is set to
be force updated to make it work with api version then the app would be redirected to play/ app store.
i would like to know how everyone handle this problem and am i doing the right way.
Is there any rails plugin or library which already takes care of this particular problem
or helps in doing so.
i know there are lot of versioning gems available but they dont take care of this issue [force updating app]
Please guide
I've worked on a project where an API for configuration was called on the Android App Startup. This API would provide 2 fields: major_version and minor_version. If the major_version from the configuration API did not match the one on the App, there would be a popup asking you to force update the App. This would be on the Start-up Screen, so you won't be able to access the actual contents of the App unless you force update your app. If you do not want a force update between 2 app versions or 2 API versions, you have the option of tweaking the minor_version.
I'm considering using the CFUUIDCreate API to build a database in my server to measure what percentage of users of each of my apps are running which version of iOS (to help me make a decision on iOS minimum supported version for future development).
My question is: Should I ask the user for permission to send the (anonymous) UUID / iOS version data pair to my server, or is it OK to do it automatically?
I ask because I could bet on the safe side and ask anyway, but most users would feel intimidated by the technical details and most likely decline. Also, the longer the text in an UIAlertView, the more likely the user won't read it.
Will Apple reject my app if I don't ask? Even if they don't, do you think I should always ask the user for permission to send this anonymous data?
What's everyone's experience implementing this kind of functionality?
OK, this is what I'm going to do, based on Nikolai Ruhe's answer but improving on a pitfall I just discovered.
Suppose user John Doe installed my app on his iPhone running iOS 5.0.
On the first launch, the app sends an anonymous request to my server that effectively increases by one the counter for 'Devices running iOS 5.0'. The app records this event and the iOS version (in User Defaults or Keychain) and does not send any further requests as long as the locally stored OS version string and the current one (returned by the system) are equal.
The next week, John upgrades to iOS 5.1 and launches my app. The app detects the OS version discrepancy and sends a new request to my server.
But if this only adds one device to the 'iOS 5.1' population, John's iPhone is now being counted twice: once as "Devices running 5.0" and once as "Devices running 5.1".
So to fix this, my HTTP request should look like this:
http://myserver.com/my_stats_scripts/index.php?app_id=com.myCompany.myApp&new_os_ver=5.1&old_os_ver=5.0
So my database can increase the number of 5.1 devices and decrease the number of 5.0 devices by one.
Of course, on the first request, the HTTP parameter old_os_ver is set to empty, and the server treats it like a new device.
If I pull this right, I no longer need UUIDs. But I am still sending system info covertly to my server. I think I'll also disclose this on the Terms of Use.
You should definitely ask for permission. The crucial bit here is that your data collecting might be anonymous, yet it can be used it to track individual users.
Web browsers send a user-agent string with every request. The difference is that they do not send a universally trackable id that would never change.
So the problematic piece in your proposal is the UUID. Why not just leaving it out? Your app would send an anonymous request once and locally store the transmitted iOS version. When the user upgrades the OS, you send another request with the new iOS version and an update count.
Using this scheme you would not transmit trackable data and still get a proper usage-by-os statistic.