I have a client who wants to create an app that checks for a user's neck posture. I have seen some weird implementations online which aren't very sophisticated so I came up with a way of doing it but I required 1 component which involves facial recognition while the App is in background mode, meaning the user doesn't have the app open and its just running n the background. I've read online Apple does not allow this feature for security reasons and I am wondering is there any possible way to convince Apple to allow me to do this? Are there special cases where we can implement it?
for example
The app checks the phone's Pitch position
The app checks wether it can detect user's face
The app uses these two properties to determine how well the user's neck is aligned with the app.
This is not currently possible. If you want to convince Apple to change this at some point,
Go to http://bugreport.apple.com/ and file an enhancement request
Include a highly persuasive argument as to why they should want this in iOS. Be sure to cover the security concerns that prevent it from already being possible.
Wait. Probably a long, long time.
Related
I’m designing a Watch app that that has uses a PIN in order to create a token session. The goal is to detect when the watch is locked/removed from the users arm in order to know when to invalidate the token and prompting to enter their PIN again when they want to use the app. If the watch stays on while they have a valid token, they won’t be asked to enter their PIN.
I was wondering if there was a way to detect if the user locks/takes off their watch in order to do this? Any help/advice would be great!
Unfortunately Apple's wrist detection API is not available to the public, which means your app can't be notified whether the watch is on the wrist or not. This is is most plausibly for safety and privacy reasons as public info whether the watch is on wrist or not could yield malicious apps.
Nevertheless, depending on how your app works, I'd recommend you to look into tracking arm movement and using that data for locking the app since the accelerometer and gyroscope values are available for use.
I'd refer to the following
Detect physical movement of iPhone/Apple Watch for detecting hand movement
In 2015 Uber was fingerprinting iPhones to reduce fraud in China.
What methods were they using to do this? Was it as simple as recording the serial number in a database? Were they using private methods?
From the NYT article:
"To halt the activity, Uber engineers assigned a persistent identity to iPhones with a small piece of code, a practice called “fingerprinting.” Uber could then identify an iPhone and prevent itself from being fooled even after the device was erased of its contents.
There was one problem: Fingerprinting iPhones broke Apple’s rules. Mr. Cook believed that wiping an iPhone should ensure that no trace of the owner’s identity remained on the device.
So Mr. Kalanick told his engineers to “geofence” Apple’s headquarters in Cupertino, Calif., a way to digitally identify people reviewing Uber’s software in a specific location. Uber would then obfuscate its code for people within that geofenced area, essentially drawing a digital lasso around those it wanted to keep in the dark. Apple employees at its headquarters were unable to see Uber’s fingerprinting."
Found more info and a potential method on this article.
Will Strafach examined a 2014 build of the Uber iOS app and found them using private APIs to use IOKit to pull the device serial number from the device registry.
https://twitter.com/chronic/status/856250223777206273
There might be more, but this alone is a blatant violation of App Store policy. Strafach confirms that the technique Uber was using no longer works in iOS 10.]
Github project here - https://github.com/erica/uidevice-extension/blob/7adc1d13946fca6fcb4b5f0b6e45911ab4a9a671/UIDevice-IOKitExtensions.m
Even I was too curious to know. I read a tweet, that basically hints that they exploited IOKits registries to do this.
Seems like they got some identifier from IOKits internals and saved it at their end to identify as device.
https://twitter.com/chronic/status/856250223777206273
This question is speaking in more general terms rather than a specific issue, but is it possible for an App to have the ability to activate and deactivate service? I know it would take cooperation from the carrier, but in theory could you have an app that essentially controls your ability to turn your service off and on? I realize there are apps that block certain features like internet access, but I'm talking about completely cutting the phones service or reactivating it all together. Is this something that could be done, or is iOS to sandboxed to allow for such access?
I have a question about running an app in the background.
I know about how to do it, but Apple does not like the way I'm doing it.
To get you on the same page, I have a security app, and I need to it monitor the device even when it is in the background. It is sort of like a burglar alarm.
I was using background audio mode, thinking it would be okay because I will be playing a sound when it is triggered. Needless to say, Apple didn't like that.
So I added a ping! It pings while active, therefor playing background audio while in the background.
Once again, they didn't like that either.
My app monitors the accelerometer as well (but not always, only when chosen by the user).
My question is, how are apps like Skype, and other similar apps able to turn the status bar red, and stay in the background? (Even some alarm apps will do this, without playing any audio or anything).
Also I can't use the notification system because it does not update fast enough if I'm monitoring the battery level. For my app I need immediate response.
I have also searched around tirelessly for this answer before I posted my question (the answers I have found, do not work for me..) :(
I would greatly appreciate any insight on this, Thanks in advance!
(If you need anymore information, please ask!)
From what I can tell from their documentation, it seems that the only way you can maintain a persistent background connection is by using one of their seven background mode keys, which I can see you've been trying since you registered for background audio. I know some alarm apps as well that use this feature (e.g. Sleep Cycle), and my assumption is that they are also using background audio mode, considering the other six modes are not remotely close to what they would need it for.
I think Apple's reasoning might be that these apps are allowed to do so, because their app is designed to be used when the user is not using the phone actively (i.e. when they're sleeping), and requires the audio to wake the user up, whereas if you are running a security app that wants to be active at all times, it may interfere with other features the user may use like Skype. The red bar will also persist at the top of the device at all times when the user is using it, which they may mistake for something that is still playing since usually when a red bar appears it means to the user that they are still actively using something. Again, I think wake-up alarm apps and others like them that aren't using persistent audio are able to get away with this since they are designed for use when the phone is inactive, so having the persistent red bar when the app is not visible is less of an issue.
In some other cases, like Nike+ (discussed here) and likely pedometers, they seem to be using the location background mode, since they often also track where you went and need to know distance. In that discussion I linked to, it looks like others were able to get accelerometer updates by registering for a background mode that applied to them. Have you tried registering for location movements? One downside I can see to that is it might drain battery life quicker, but if you check location infrequently it might not be too bad? Another is that I don't think you can directly play audio when in location background mode, but you could try to trigger a sound notification? :) That might be a nice workaround for it if that works for your app.
Again, the reasoning I have for why these apps are able to do it is just based on how I've seen other apps operating, and Apple may have different reasons for why it accepts them, but that was my best way of thinking why your app got rejected for using those modes while the others are able to do it. If location isn't what you're looking for, unfortunately I'm not sure from what it sounds like your app is doing that you'd be able to operate it continuously in the background in the way you're expecting.
Being responsive is a need for every app. Users want to have apps which have their content ready when they open it, so developers should use Background Modes to make their apps more user friendly.
Turning on the Background Modes capability
Go to Xcode and open your project.
In your app target, navigate to Capabilities tab.
Turn on Background Modes.
Background Fetch
Background fetch is a new mode that lets your app appear always up-to-date with the latest information while minimizing the impact on battery. You could download feeds within fixed time intervals with this capability.
To get started:
1- Check Background Fetch in capabilities screen in Xcode.
2- In application(_:didFinishLaunchingWithOptions:) method in AppDelegate,
Reference: https://medium.com/#javedmultani16/background-modes-in-ios-3da25b9e6474
You can use background modes only if you actively use the activity that keeps the app awake: e.g. continuously playing audio is a valid use of the audio background key. They'll look pretty hard at whether you really need the access you request, and if not they'll reject you (as you've already found out), as background services drain the battery considerably more than others.
From the docs:
These keys should be used sparingly and only by apps providing the indicated services.
Short story: I think you're out of luck with your proposed implementation.
Building a multi player iOS game where players compete one against the other. Nature of the game is synchronous. Basically, players either invite each other through facebook, email, etc and then start playing.
We debate what is the best strategy for facilitating the real time communication between players (sending events, etc). Coming from web development, we used comet and long polling which worked great. However, it's not clear what's the best way to achieve that on iOS.
Seems like APN (Apple Push Notifications) is not suitable in our case for two reasons: the delay can be pretty significant, up to few seconds, as far as we understand. Also, using APN requires the user to authorize notifications. If the user doesn't authorize this then it won't be possible to play the game.
Also, we understand Apple's Game Kit (Game Center) can be of value in our case however it's not clear how it interacts with invites through facebook etc. Also, not clear if we need to get into bed with Apple's Game Center and how it'll affect the user experience.
Any guidance on this matter as well as other options that you might think of would be greatly appreciated.
Thanks for your help.
Before you read the rest, a disclaimer: I work for Realtime.co but I do believe I can help here so I'm not trying to "pitch a sale".
If you need to have real time updates, you can check out Realtime (www.realtime.co). It's basically a set of tools for developers to use real time technologies on their projects. It uses websockets but does fallback to whatever the user's browser supports (such as long polling, for example) if you are using a browser (which is not your case, but it's always good to know).
Behind Realtime you have a one-to-one/one-to-many/many-to-many messaging system that will transport your messages to and from your users.
There's a iOS API too which you can use in your project. You can download it here: http://www.xrtml.org/downloads_62.html#ios and check the documentation here: http://docs.xrtml.org/getting_started/hello_message.html#ios.
There's also a plus which is the fact that the Realtime framework is actually cross-platform. This means that you can even have your iOS players to communicate with players using Android, Windows Phone, HTML5, Flash, etc. if you decide on expanding your game to other platforms.
I hope that helps!
I'll just provide some insights on the question.
APN should never be used for synchro communication as for iOS at least, you'll never have both way communication (basically the Apple APN servers are pushing an information to the device).
You should probably play with C sockets in order to open a tunnel (depends if your game is real time or not).
Using the Apple Framework GameKit is great! But might take some time to understand all the functionnalities.
Check out Gree
https://developer.gree.net/en/
Parse:
https://www.parse.com/
Sparrow:
http://gamua.com/sparrow/
There are a few things that your talking about, there is the joining/starting of a game, and then the communication between the players. They are not necessarily related.
You can use game-center and at the same time another framework for facebook, they are not mutually exclusive (but it would be more work.)