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.
Related
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
I want to update an iOS application, so it only contains a splash screen that says: we are working on updating the app as soon as possible, stay tuned for the next version.
I don't want to remove it from sale, and i also don't want new users to interact with the application, i just want to show them a page with a message.
Is this against apple rules? will they accept my update?
Too simple applications usually don't pass through the Appstore validation.
Have a look a the official documentation : App Store Review Guidelines.
2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may
be rejected
It's likely it'll be blocked for 2.1 (App Completeness), or 4.2 (Minimum Functionality), but can't be answered conclusively without trying it.
for situations like these you should implement some kind of functionality in your app that lets you control those "maintenance periods" without updating the app. for example some kind of API that returns a special http status code when the app should not be usable for a specific time. then you can react on that status code and show the user some kind of "maintenance message". as soon as you're done you can easily reenable functionality.
This almost certainly won't make it past review. The only way you could do this (and I wouldn't advise it) is to add a splash screen behind a feature flag that you activate remotely after review.
In my app, Can I check that which app is being used by a user right now, while my app is running in background?
If so, Is there any API available to get that info?
thanks in advance!
No. There's no public API that lets you a background app find out about the foreground app, or get a list of running apps, or anything like that.
The only mechanism for finding out about other apps on the device is +[UIApplication canOpenURL:], which you can use in some cases to find out whether a specific custom URL scheme can be handled. From that you can often guess that a particular app is installed, although the method really only tells you that some app that can handle the given scheme is installed. However, you still can't find out if that app is the foreground app, or even if it's running at all.
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
Assuming the user has not launched your app yet, but it has been run before. Is there a way to still "push" news/updates?
To explain what I mean:
Imagine the user installed "your-restaurants-in-your-area" local orientated app, and configured the app in some setting to notify the user when new restaurants open... However, the user forgets to run this app at a daily basis. Is there a way for the app to auto-show news inside iOS?
I have found this for XE4 where Anders is stying to help people get it working with XE4
http://blogs.embarcadero.com/ao/2013/05/02/39456
http://blogs.embarcadero.com/ao/2013/05/24/39472
After further searching (I missed this first round) I found this:
http://edn.embarcadero.com/article/43239
It requires editing Delphi XE4 bundled source files (i.e. so it is not officially supported / made easy in XE4), but it seems it can be made to work. (I have not found any official mention of official "built-in" support in XE5.)
I upvoted the answer given sofar since it was helpful in a way.
The question is not related to Delphi…
It is impossible to auto-run/unattended-run applications in iOS.
If the user has never opened your application, you will not able to send him “Push notification”, because your application must be registered with the token. Usually the application registers on the start.
Let’s assume the user launched the application at least once, and your application successfully registered the token for “Push notification”. In this situation, you will able to notify the user when the new restaurant will be opened.
The problem in this situation that you don’t know the physical location of the user. Maybe you can add the region of interests in your applications, so you will know to whom to send the notification.