We are looking to develop an iPhone App communicating to webservices that is hosted internally at the customer site. Note that this is our first iPhone native App and using monotouch to do the job.
We will be maintaining the code and release updates periodically. However, the users needs to update only the version required based on thier local webservices and backend processes. For example, if the user is still using the version 1 webservice don't need to update the App at all, where as the users with version 2 needs to update to the matching App and so on.
We want to control the updating process or at least find a solution where if the user updates to the latest App, it won't come up with an error because the connected webservice is out of date.
We were thinking of the following processes, but nothing seems to be solving the issue.
1) Leave the app on the appstore but control the update processes somehow based on the webservices version. So when a user try to update, it will not update unless the required webservices is available. (Annoying part on this is users may be prompt that there is an update available even though those are irrelavent for them.)
2) Control the update outside the AppStore. Something similar to In-house development.
3) Stop the updating process entirely from the client, and only trigger the updates from the webservices end.
i.e Inform the client that it needs to update when the webservices updated, and the client will run the update process at that point.
However, it could be tricky, if the customer's updated to the webservices version that is not the latest.
1) There is no way to do what you want to do with Apple's AppStore, either an app can be updated or it can not, you can't add additional conditions that requires running code on the device itself.
2) That leaves in-house enterprise deployment - but this is restricted to deploying to your own company, you can't deploy to different clients this way.
3) You can't stop updates from your app, since you can't run code when an app is updated.
There is a 4), but it requires more work on your end:
4) Have your app support support older webservices, either through some sort of configuration the user can set or it query the web service for its version and selects accordingly. This has the additional advantage that an update can be deployed to all the devices first, and once all the devices have been updated, update the web service.
I would propose a fourth option: dont control/limit updating :)
Ship an app that uses a Wrapper object to access the service and that object internally handles different versions of the webservice.
apart from that.
1) doesnt work (if I get what you're doing: trying to influence the appstore updating)
2) sounds doable, and if you dont care for the appstore, it works
3) why? users love updates :) + there will be critical bugs
Related
My client needs to find a way to automatically push app updates to a number of iphone 3gs devices remotely. These devices will be in guided access mode so the users will only be able to access the app in question.
I believe we have two option for distribution:
B2B custom app via the Volume Purchase Program
In-house app released with the Apple Enterprise Program
Having researched our options I can see that over the air app updates can be achieved by either:
Building an in-app update functionality to check for new updates (Enterprise only I am guessing?) and automatically update and restart the app
Using an MDM such as http://www.air-watch.com/ (as I understand Apple Configurator must have devices plugged in via USB to work?)
I am wondering if anyone can tell me whether either of those options are possible with the devices being in guided access mode?
Or are there any other solutions, which I have missed, that can automatically manage the app remotely while the device is in guided access mode?
You can solve this with an Enterprise distributed app.
App only. Update check for an OTA-Update from your app when the app is coming to the foreground (or some other metric at your clients leisure, like added time delay, etc). Basically self explanatory; you implement a call to your clients/your API to check the version and inform the user of a new one. The update can either be optional or mandatory (preferably announced by the API and changed when needed); present the user with an alert about it. The user acts upon it and you OTA install via an ITMS link provided by your API call. And that's it.
MDM. Tbh, I'm a bit on shaky ground here. Theoretically this is all possible via MDM too, however I am not sure if it is the (varying) MDM solutions or some misconfigurations, but clients usually seem to lose control after some time.
Both. Yes, you can perfectly well live with both. MDM while everything is fine, and as a backup a well structured App+API mechanism to push the OTA updates out. This is especially useful if you have customers where some departments are under MDM and others are not. So, some may get it via MDM (and if all else fails via the App itself), the rest will get it via the App.
The tradeoffs are a matter of personal preference, if there is a fully working MDM solution in place the update will be pushed out and the user however 'malicious' can do nothing against it. But the same is true for the 'App only' solution, as you have the option to not let him use the app if he does not update (either by not providing a cancel button or, as you are in an enterprise environment and there it is allowed doing an exit(0)).
From experience I prefer any solution that has the 'App only' option as it is the last fallback if anything on client side fails. Whatever may be added on top is just sugar to the cake.
While not strictly relevant, the 'App only' solution always goes well with Push Notifications when an update came out.
I know that when you publish a new version of your app, it goes through an approval procedure from iOS, Android or Windows Phone marketplaces. Perhaps not very thorough one like the first time your post your initial version, but still you need to wait a bit until your new version is available to users.
I was wondering if this scenario if possible.
I post my new version for approval
Marketplace verifies and approves the version but does not publish it
I get a notification that my new version is ready and approved
I press the last button to publish the already approved version
Do you know if there is such a possibility in the various marketplaces?
This would be useful for marketing purposes (make a new version available on all marketplaces at the same time) or even to minimize technical issues (minimizing the different versions running on clients, especially if there connect to a server that otherwise would need to be backward compatible).
Yes, you can choose when to release an app (or new version of an app) at a time you choose, once it has passed the certification/verification process.
What you can't do is have it available to all users at exactly the same time. When you make the new version live it make take up to several hours before it has sync'd to all servers that each store/marketplace uses. This means you can't say that "at 9am on Tuesday you'll be able to get the new version" without actually making it available several hours earlier so it has time to spread to all servers. This may or may not be an issue.
In terms of managing backwards compatibility of your backend with regards to different versions of your app(s) this is something you will need to manage yourself. There is no marketplace which will automatically force all installed versions of an app to be updated before they can be used.
You will need to manage this within the app (i.e. check if it's the latest version and if not force the user to upgrade before they can continue.)
Realistically you should create your server to be able to support multiple versions of the client. Even if you do force all users to update before they can use a new version of the app/backend you'll still want to test the live servers while the old client apps are still being used.
I can't vouch for the iPhone, but for Windows Phone, yes, when you submit an app update, you can set it to publish manually, and with Android, there is no certification, so you can just publish it whenever you're ready.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
When my iPhone application start, I want to notify the user if there is a new updates / version released on App store.
Does anybody have any ideas or has anybody else achieved anything similar?
Thanks
Use Nick Lockwood's iVersion library. It's whole purpose is to notify the user when new updates are available.
iVersion is a library for dynamically checking for updates to Mac/iPhone App Store apps from within the application and notifying users about the new release. It can also notify users about new features in the app the first time they launch after an upgrade.
Purpose:
The Mac and iOS App Store update mechanism is somewhat cumbersome and disconnected from the apps themselves. Users often fail to notice when new versions of an app are released, and if they do notice, the App Store's "download all" option means that users often won't see the release notes for the new versions of each of their apps.
Whilst it is not permitted to update an App Store app from within the app itself, there is no reason why an app should not inform the user that the new release is ready, and direct them to the App Store to download the update.
And if your app is not on the App Store, either because it's an in-house/enterprise iOS app, or a Mac app delivered to customers outside of the store, you can't use the App Store update mechanism anyway.
iVersion is a simple, zero-config class to allow iPhone and Mac App Store apps to automatically check for updates and inform the user about new features.
iVersion automatically detects when the new version of an app is released on the App Store and informs the user with a helpful alert that links them directly to the app download page.
Or if your app is not on the store, iVersion lets you specify a remote plist file to check for new releases, and a download URL where users can get the latest release.
iVersion has an additional function, which is to tell users about important new features when they first run an app after downloading a new version.
These excerpts were taken from the Github page here, where you can download it. There is also a comprehensive tutorial on installing and configuring iVersion, so I recommend that you check it out.
Hope this helps!
To give a comprehensive answer. There are basically two ways you can go here. Depends on where you want to put the responsibility.
App checks for new versions on server
Using this approach, you would add a method to your app that is being called on every launch to compare the current version of the app (wherever you want to save that) with the version stored on the server. To achieve this, the server must implement a small web service that returns the latest version as a string or something else very simple. No rocket science there.
Server pushes new version information to app
This way you implement more code on the server-side to do a Push Notification to your app which informs the app about the new version. Advantage here is: Less client-side code and less effort to check, because the version check does not happen every time the app is started but instead only once the new version is actually released.
you can do a call to your server when the app starts.
and that way check for a news item in your database, for example.
When the server gives you something. show it in an alert.
On the other hand, when there is an update in the appstore, doesn't the iphone give a warning?
APNS - Apple Push Notification System
Try it and google for ready server solutions.
Update: Okay, lets get it longer -
APNS is the best way to inform user about something new. It works with every state of the app - even when app closed - and it helps to avoid unnecessary requests to server.
But you will need server to send pushes - if you can write it by yourself - it's nice, but the are some services to create backend for your app (no links - no ads, just google it).
To find out how to start with APNS on the client side and how to create all needed certificates and keys read this one
Just check the latest version by communicating with your server and compare with the current version of app when the app starts up, if there is a newer version, notify the user.
Apologies in advance for the plug - but I think a service I built extending the concept from my experience building many apps solves this problem. Look at CleverStork - an Update Manager for Apps
There is something known as Silent notifications from iOS 7 and above, you can use that for
this
Is it possible to automatically force an update of all installations of an iPhone app without requiring interaction from the users?
According to this thread it is impossible to do so for apps deployed on Apple's public app store, but another more recent thread describes a way to at least inform users of updates, but still forces them to take action manually. With the Enterprise Program becoming available to most companies now (the requirement of 500+ employees has been dropped) can we hope to achieve it with the Enterprise Program?
The reason I'm asking is that automated push-updates of applications are a common demand and indispensable requirement by many businesses that use mobile devices. Blackberries have always won over iPhones in the past, because they had this feature while iPhones did not. Has the situation changed now?
Update: Apparently, there is another problem. Apple has a limit on the size of app downloads of 20MB over GSM which to my understanding also applies to deployment within the Enterprise Program. Unless all users consistently have access to a WiFi connection, this is another limitation that needs to be taken into consideration.
Update 2: I have submitted a feature request to Apple. Maybe it helps to expedite the improvements.
I don't believe you can force an update, though you can:
Remotely disable an existing app, if urgent, and
Design your app such that when it is outdated it alerts the user and provides a one-tap link to download a new version (technically two taps, one to load the web page with the app and one to install the new version).
It's not the ideal system you note would be so helpful, but it's an improvement over the earlier system where users had to sync with iTunes at a desktop/laptop in order to perform the upgrade.
I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.