iOS Swift + IOS + Bluetooth Questions

[Karamelli]

Hi,

I am new at around you and also IOS programing with swift language. Nowadays, I am dealing with a project which uses bluetooth in order to communicate with beacons and cloud message service which is Firebase.

Actually, I did a part of Firebase side. However, I need to help for bluetooth side.

Firstly, I need to learn, how can I launch my app after start up of phone? (Like WhatsApp)
- WhatsApp can do it. You restart your phone and after start up, messages come. You don't need to open WhatsApp after restart of phone.

Secondly,
- I need to learn, how can I continue bluetooth search in background. Not only using home button. I mean that App has killed after home button. (Think that, you pushed twice home button and killed my app here)


Best Regards,
Karamelli

 

[Mascots]

Firstly, I need to learn, how can I launch my app after start up of phone? (Like WhatsApp)
- WhatsApp can do it. You restart your phone and after start up, messages come. You don't need to open WhatsApp after restart of phone.

Secondly,
- I need to learn, how can I continue bluetooth search in background. Not only using home button. I mean that App has killed after home button. (Think that, you pushed twice home button and killed my app here)


Best Regards,
Karamelli

WhatsApp uses Apple's push notification service to deliver messages. The app is not launched after restart: iOS checks and fetches notifications pending for the device from that service then handles them. The app itself is not running to do this. Look into APNS To understand this process.

If the app is killed, you loose (nearly) all ability to the background. There is nothing that can prevent this.

 

[Karamelli]

Okay,

There is no way to work only timer block and in this block only check time if time is ready, send notification after killing program?

I mean that Can killed program send notification with when a time, which I decided, has come?

 

[bjet767]

Apple has some very restrictive background running requirements for iOS. As the poster said push notifications is huge and that requires you register with Apple to make those happen. Unlike Android iOS is NOT an open system and probably never will be. You must follow the rules or else your app will not make it to the store.

Apple does have a system for corporations and users that manages and can communicate directly to the devices through what we would call a "Profile," but again this requires you work with Apple.

Also you can not "kill," close or shutdown an iOS app from the app. The only way is for the user to close it is by sliding the app closed from the user interface.

Your app can be "killed" (as you put it) by the OS because of memory issues or some other conflict. Unless you have it working an authorized task in the background, like location services, audio, or something similar, it will eventually be resigned to essentially a no activity status.

 

[firewood]

Also you can not "kill," close or shutdown an iOS app from the app.

Not true. There is a documented plist key that prevents an app from running in the background. If such an app then launches another app (via registered URL) the OS will then kill the first app.

 

[bjet767]

There is a documented plist key that prevents an app from running in the background. If such an app then launches another app (via registered URL) the OS will then kill the first app.

Ok let me be more clear, Apple will reject your app if you add a button, menu item or some other feature which purposely "kills," closes, quits or shuts down the app. What you are talking about are features in iOS that protect memory and the sand boxes of apps.

iOS is purposely not OS X or Windows that allow apps to have quit menus.

See this page

https://developer.apple.com/library/content/qa/qa1561/_index.html#//apple_ref/doc/uid/DTS40007952

 

[firewood]

Ok let me be more clear, Apple will reject your app if you add a button, menu item or some other feature which purposely "kills," closes, quits or shuts down the app.

Not true. Plenty of apps send web pages to Safari. Some of those apps include the documented plist key. The OS will kill those apps upon using the app's send-URL-to-Safari button (as the developer intended).

 

[bjet767]

Not true. Plenty of apps send web pages to Safari. Some of those apps include the documented plist key. The OS will kill those apps upon using the app's send-URL-to-Safari button (as the developer intended).

Firewood have you looked at the Apple app and their guide for apps ever?

They specifically mention not making any other way that closes the app and removes it from the background (where the user will see it if they double tap the Home button). They even mention to not encourage the user to close the app from the background by sliding it away as part of the app's usage as part of any function needed to make the app work correctly, such as cleaning up open files or memory use.

The only official way Apple wants a user to kill or completely remove it from sitting in the background is by sliding it closed. Since I haven't tried what you are mentioning on my apps I would assume the app is still in the background and can be seen by double tapping Home or it's an undocumented feature developers slip by the app approval process.

Ask the Apple developer team if this is knowingly allowed for us please.

Here's a link (you ignored my last link reference) to some of the iOS plist items. Please point to the one you keep mentioning, rather than just saying "untrue" and giving the readers a vague reference.

https://developer.apple.com/library...SKeys.html#//apple_ref/doc/uid/TP40009252-SW1

Let me throw one more link to you, using one of the plist items (you figure it out) still has the app showing in standby or when home is double clicked.

https://stackoverflow.com/questions...exitsonsuspend-is-the-an-equalvalent-for-ios8

Now you will probably say that is what I meant by "kill" while I will state again, and make clear, Apple wants the app to be only removed by sliding it away and that is what I mean by "kill."

Maybe you can show us some code where your idea is being used?

 

[firewood]

You can test it yourself by building an iOS 10.3 or 11beta test app that includes this documented plist key. Run it from the Xcode debugger, and the debugger will tell you that the app was killed by the OS upon any backgrounding (including by calling up a Safari web page). Note that you may be tricked by seeing a screenshot of the killed app in the task switcher, but the debugger will show the process as dead dead dead.

A web search does not turn up any developers who have had their apps rejected for using the documented UIApplicationExitsOnSuspend plist key: https://developer.apple.com/library...Keys.html#//apple_ref/doc/uid/TP40009252-SW10
This documented key still shows up in the latest Xcode project's Info.plist drop down.

 

[Mascots]

From what I understand: You certainly cannot have a button labeled "close" that then sends you to a web app (against UI design), but you def can send someone somewhere else with UIApplicationExitsOnSuspend set which will/should terminate the app from memory immediately. It will remain in their multitasking tray, but will need to be relaunched on selection.

 

[firewood]

From what I understand: You certainly cannot have a button labeled "close" that then sends you to a web app (against UI design), but you def can send someone somewhere else with UIApplicationExitsOnSuspend set which will/should terminate the app from memory immediately. It will remain in their multitasking tray, but will need to be relaunched on selection.

Yes. And you can label your close button something like "goto support web site", etc.

 

[bjet767]

It will remain in their multitasking tray, but will need to be relaunched on selection.

Firewood you keep defending but not admitting this is what is being talked about.

To "kill" an app using this feature basically means all the memory stuff is closed but the app still remains available. The point is Apple will not let one remove the app from the tray in any sort of way and as stated does not allow close buttons.

Killing an app in my post has always been removing and requiring the user to restart it from the home page. You want to say it's something else. Apple does not want apps to be closed, quit or anything else which appears to be like the quit feature on OSX or Windows. They want the user experience to be consistent.

I guess this exchange has never been made clear, however Mascots seems to understand.

BTW the real challenge in writing iOS and a Watch apps isn't killing it, it's keeping it running in the background or waking it up when needed. Something Apple also pays close attention to when one submits an app for review.

 

[firewood]

To "kill" an app using this feature basically means all the memory stuff is closed .

"kill" is a Unix OS term with respect to OS processes, and iOS is a Unix derivative. The app's OS process can be killed by the iOS Mach kernel, in spite of false info being presented by the task switcher UI.

 

[bjet767]

Yes I know iOS and OS X are both a UNIX derivative, and your continued arguments ignore the point Apple makes and wants it's developers to pay attention to.
[doublepost=1503077428][/doublepost]

"kill" is a Unix OS term with respect to OS processes, and iOS is a Unix derivative.

You might notice that when the iOS kernel "kills" the app it is also normally removed from the "task switcher."

And why would iOS "kill" an app? Far different reason than when done in the manner you keep insisting on.

Back to my original point, Apple does not want a developer to write an app which has a quit feature. They want the developer to gracefully take care of any background processes or memory issues that need to be dealt with while the app is not doing anything.

If you're a developer and have an app in the store you'd know this.

 

[firewood]

And why would iOS "kill" an app?
.

Because the documented by Apple exits-on-suspend key was set in the app's plist and any other app was called to the front.

So, the reason why is to conform to their own iOS documentation.

 

[Mascots]

You might notice that when the iOS kernel "kills" the app it is also normally removed from the "task switcher."

Well, if iOS kills an app, it will not be removed from the task switcher.
There are several reasons for the system killing an app: crashing, exceeding background limit, system responding to high memory pressure, it contains the kill-on-suspend key... regardless of the reason, iOS wants to give the impression to the user that the app is still running.

The only event in which that app is removed from the switcher is by user intervention, swiping an app up from the collection.

And the only difference between an iOS kill and a user task switcher kill is that the latter is gone from the switcher and prevents the system from rebooting the app for any sort of background callback (including VoIP, background refresh, and *maybe* hardware). If the system kills the app (assuming it wasn't a crash, invalid, or supposed to), it retains permission to restart the app and jump through the delegate to properly act on some of those background types.

What firewood seems to be talking about is just having your app terminate when left; if left via a Safari/app link or home button while having the ExitsOnSuspend key set, the app is killed by the system. It doesn't have the impression of "quit" since you're not being returned to the home screen and its left in the switcher, but for all intensive purposes has been killed.
It's also important to remember that the app, even with ExitOnSuspend set, can resume from where it was when it is relaunched by saving it's state in the delegate's termination call, removing the impression the app restarted when left and come back to even when killed in that process (ohhhh the early days of iOS).

Basically, an app can't quit (impression of), but it can be killed (action of) on leaving it. It seems like you two are getting at two different things here.

 

[bjet767]

Well, if iOS kills an app, it will not be removed from the task switcher.

Not my experience. I have a very extensive app which uses location services, BT and a Watch connection. When iOS kills it the app is gone from the switcher (double tapping Home, so we are on same page) and must be restarted. The reason is the message between the app and the Watch app (using HealthKit) are not fully enabled, sadly the response is it is. I'm also using asynchronous work because it has to work behind the UI and current loop.

But the fact is it kills and removes.


Ok dudes here's the quote from Apple, love it or just argue on.

Guidelines

"Don’t encourage rebooting. Restarting takes time and makes your app seem unreliable and hard to use. If your app has memory or other issues that make it difficult to run unless the system has just booted, you need to address those issues."
[doublepost=1503087408][/doublepost]

Basically, an app can't quit (impression of), but it can be killed (action of) on leaving it. It seems like you two are getting at two different things here.

Yep you get it.

Firewood just wants to be right and I'm believing he or she doesn't do much more than play with app programming.

This stuff is about the user and Apple's way.

 

[Mascots]

But the fact is it kills and removes.

I have not come across a single situation ever in which iOS kills an app and also removes it from the task switcher and I have been at this for a very very long time. Under what conditions does this occur? As firewood and I have said, the system can kill your app at ANY time for any reason so it just doesn't make sense to make this sort of action.

If the system kille behind the users back, it will remain as if the user has not done anything; the app remains in the task switcher and only certain background tasks are suspended. This is not unusual. In my switcher alone I have 15-20 apps that were terminated by the system.

The quote you pulled involves rebooting your app if you hit a memory threshold or some other state that can otherwise handled; it has nothing to do with the state of apps across backgrounding or not...

 

[bjet767]

I have not come across a single situation ever in which iOS kills an app and also removes it from the task switcher

Serious?

Just 10 min ago iOS 10.3.3 iPad 10.5 started a crossword puzzle app and it crashed, not in switcher, (just so we are on same page a crash is something which cause iOS to kill app, if this is not the same idea then we are thinking differently on this).

My app in development opens a Watch app to send messages back and forth. Although the session is ready and the Watch app is reporting installed the iOS iOS app will crash when it attempts to send a message to the watch app before it is fully loaded. Not supposed to do this and even with all the error messages and other precautions it kills the iOS app and removes it from the switcher. My suspicion is I use, as I mentioned before, asynchronous functions to get data from HealthKit beacuse it does not always operate in the current loop.

I've been developing iOS apps for over five years, objectiveC, and I see apps (not my own) crash and gone from the switcher regularly. So I suppose we're talking something different.

Again I assume the switcher is double tapping home.

Basically never encourage an app developer to violate any of Apple's guidelines even if the idea will compile and test. Hate rejection from App Store review. Yes I had one, but it was because I did not provide way for them to test data connection to private URL. Once I provide access it was approved.

Oh I might add I have found Apple seems to have undocumented limitations on its BT capabilities, especially while messaging between phone and Watch. It seems to prioritize that communication and somehow ignore other BT devices until the messaging is completely completed.

 

[Mascots]

Write an app that immediately exits or crashes in didFinishLaunchingWithOptions - it will remain in the task switcher. Literally just did it. Just to test again: I just crashed my own app and it remains in the switcher.

The only event in which an app is removed from the switcher is by user intervention or uninstalling the application. The system will never remove an app from the task switcher when killed because an app can be killed at any time (unexpectedly or exit) and iOS gives the appearance they're still running to the user (whether they're dead, active, or using some background task). I have never seen the system do anything other since its introduction on iOS 4.

The only thing involving the switcher that a developer/system can manage is the screenshot. Beyond that, its the users domain. That's why the kill on suspend key has no affect on the UX exit rule.

Also: you're talking about messaging between watch and phone using WatchConnectivity? It should never produce crashes while messaging a counterpart app if unavailable used properly...

 

[bjet767]

Also: you're talking about messaging between watch and phone using WatchConnectivity? It should never produce crashes while messaging a counterpart app if unavailable used properly...

I'm betting we're talking about something different, because as long as I've been using iOS crashed apps have disappeared on my devices. But a suspended app is different.

Ok I am using watch connection correctly, check my code, use break points, and yet with multiple BT devices connected to app the watch connection crashes it until the watch app is fully running. Then everything is ok.

I have three devices connected to the app besides the watch. It never crashes except when the watch is connected, the associated app is loading and the iPhone app is waiting for a message.

Yep the connection shows available and ready.

 

[bjet767]

Mascots:

OK i get what you are saying about a crash and it's different than what I'm writing about.

I've forced "crashes" but more likely a controlled "terminate" or "abort" by the system. Yes, that does leave a view in the selector. Basically, it's Terminating because of an uncaught exception of some sort and I normally find those things relatively easy to trace out.

The kind of "crash" I see is where the app just completely dies as if it was never loaded, no trace whatsoever. As I wrote my XWord puzzle app crashed last night, gone from the selector, and I have seen others do the same.

I used this code to test a controlled crash:

[self performSelector:NSSelectorFromString(@"crashme:") withObject:nil afterDelay:10];

It throws this "terminating with uncaught exception of type NSException" and then calls system terminate() and the abort(). So it really isn't a "crash" but a controlled termination.

 

[firewood]

Not my experience. I have a very extensive app which uses location services, BT and a Watch connection. When iOS kills it the app is gone from the switcher (double tapping Home, so we are on same page) and must be restarted.

If seems that if an app fails early enough during its initial ObjC inits or launch, it may never even get put into the springboard task switcher in the first place.

 

[Mascots]

I think firewood’s got it. That’s more or less the condition I was grasping for and good to know I guess.

As far as WC: it really sounds like some sort of unstable or threading issue. It’s been while since I’ve dipped into watch developement, but that is very unexpected behavior. Best of luck, though!