Can we unlock content within an iOS app based on real life accessories? - ios

We are part of the Apple MFI program.
We are designing a children’s toy that connects to our iOS app via the iPod Accessory Protocol.
There are multiple configurations of the toy.
We would like to unlock content within the app based on the configuration of the toy.
We are wondering if this is admissible under the app review guidelines? Specifically sections 11.1 and 11.2.
https://developer.apple.com/app-store/review/guidelines/
Thanks,
Dustin

I think your answer is in guideline 11.16 of the document:
11.16 Apps may enable additional approved features or functionality when used in combination with specific approved physical products (such as a toy) as long as the additional features and functionality are either completely dependent on such hardware (for example an App that is used to control a telescope) or also available through the App without the physical products, such as by way of reward for achievement or by use of IAP.

Related

Restrict future Apple Watch apps to capable devices only

I'd like to restrict the sales of my next app to devices that are able to control an Apple Watch (iPhone 5 at least).
I can't find (in the doc or on Internet) which value for UIRequiredDeviceCapabilities I should put in the info.plist file.
There is currently API for knowing whether a device is paired with Apple Watch.
Even simply from an iOS app review perspective, if a user downloads an app onto their iPhone that app is expected to provide value regardless of any external products.
See Apple's App Review Guidelines for more detail
There is no such API.
As you are also no doubt aware, requiring iOS 9 will also not assist you as it runs on iPhone 4S. While it is speculation, it is possible that this will de facto change if iOS 10 is released in September/October 2016, as expected, as that may remove support for older iPhones that cannot be paired with an Apple Watch (for mostly reasons of performance, unrelated to Apple Watch capability).
However, if you are wanting to do this because you want the app to only be used with the watch, be aware that App Store review requires that apps with WatchKit extensions need to also provide useful functionality in their own right, and cannot be solely the code backend for a watch app. Therefore, you would be expected to provide functionality to users who do not (and even cannot) attach an Apple Watch to their phones.

Universal App using Health Kit

I'm working on an App which uses some new iOS 8 Health Kit (HK) features.
At present the iPad doesn't get the Health app, so can't use HK. Since the HK features are not a major part of my app functionality, I could happily leave them out of the iPad version.
My problem is that there seems no way to get a universal app running on iPad once the HK entitlements have been added, even if no use is made of HK functionality.
Does anyone know any different? Is there a way (for example) to have separate 'per device' entitlements?
Thanks!
If you want to use HealthKit, Framework Reference clearly states that your app should be primarily designed to provide health or fitness service. If your app is not a health or fitness focused app, you might not able to submit your universal app .
In addition, your app must not access the HealthKit APIs unless the
app is primarily designed to provide health or fitness services. Your
app's role as a health and fitness service must be clear in both your
marketing text and your user interface. Specifically, the following
guidelines apply to all HealthKit apps.
https://developer.apple.com/library/prerelease/iOS/documentation/HealthKit/Reference/HealthKit_Framework/index.html
Removing healthkit from Required device capabilities in my Info.plist solve this issue for me.

Reading NFC Tags with iPhone 6 / iOS 8

Now that Apple just announced the iPhone 6 will have an NFC chip, does anyone know if iOS 8 will enable reading/detecting RFID tags for the iPhone 6 device? Anyone have any details to share on this?
The iPhone6/6s/6+ are NOT designed to read passive NFC tags (aka Discovery Mode). There's a lot of misinformation on this topic, so I thought to provide some tangible info for developers to consider. The lack of NFC tag read support is not because of software but because of hardware. To understand why, you need to understand how NFC works. NFC works by way of Load Modulation. That means that the interrogator (PCD) emits a carrier magnetic field that energizes the passive target (PICC). With the potential generated by this carrier field, the target then is able to demodulate data coming from the interrogator and respond by modulating data over top of this very same field. The key here is that the target never creates a field of its own.
If you look at the iPhone6 teardown and parts list you will see the presence of a very small NFC loop antenna as well as the use of the AS3923 booster IC. This design was intended for custom microSD or SIM cards to enable mobile phones of old to do payments. This is the type of application where the mobile phone presents a Card Emulated credential to a high power contactless POS terminal. The POS terminal acts as the reader, energizing the iPhone6 with help from the AS3923 chip. The AS3923 block diagram clearly shows how the RX and TX modulation is boosted from a signal presented by a reader device. In other words the iPhone6 is not meant to provide a field, only to react to one. That's why it's design is only meant for NFC Card Emulation and perhaps Peer-2-Peer, but definitely not tag Discovery.
There are some alternatives to achieving tag Discovery with an iPhone6 using HW accessories. I talk about these integrations and how developers can architect solutions in this blog post. Our low power reader designs open interesting opportunities for mobile engagement that few developers are thinking about.
Disclosure: I'm the founder of Flomio, Inc., a TechStars company that delivers proximity ID hardware, software, and services for applications ranging from access control to payments.
Update: This rumor, if true, would open up the possibility for the iPhone to practically support NFC tag Discovery mode. An all glass design would not interfere with the NFC antenna as does the metal back of the current iPhone. We've attempted this design approach --albeit with cheaper materials-- on some of our custom reader designs with success so looking forward to this improvement.
Update: iOS11 has announced support for "NFC reader mode" for iPhone7/7+. Details here. API only supports reading NDEF messages (no ISO7816 APDUs) while an app is in the foreground (no background detection). Due out in the Fall, 2017... check the screenshot from WWDC keynote:
From digging into the iOS 8 docs that are available as of Sept 9th 3:30pm there is no mention of developer access to the NFC controller to perform any NFC operations; that includes reading tags, writing tags, pairing, payments, tag emulation... Given its an NXP controller the hardware has the capability to perform these features. They did mention a 3rd party app for the watch that allowed a hotel guest to open their room door with NFC. This is a classic use case for NFC and gives some indication that the NFC controller will be open to developers at some point. Remember, the watch is not supposed to be released until Q1 2015. So for now I'd say it's closed but will be open soon. Given the 'newness' of contactless payments for the general US consumer and the recent security breaches its not surprising Apple wants to keep this closed for a while.
Disclosure: Im the CEO of GoToTags, an NFC company with obvious vested interest in Apple opening up NFC to developers.
--- Correction & Update ---
The hotel app actually uses Bluetooth, not NFC. NFC is still often used for door unlocking, just not in this one example. NFC could be used if the watch has an open NFC controller.
I do know that Apple is aware of all of this and is discussing this with their top developers and stakeholders. There has already been massive negative push back on the lack of support for reading tags. As often the case in the past, I expect Apple to eventually open this up to developers for non-payment related functionality (reading tags, pairing). I do not think Apple will ever allow other wallets though. File sharing will likely be left to AirDrop as well.
--- Update on March 23rd 2016 ---
I am continually asked for updates about this topic, often with people referencing this post. With Apple releasing the iPhone SE, many are again asking why Apple has not supported tag reading yet. In summary Apple is more focused on Apple Pay succeeding than the other use cases for NFC for now. Apple could make a lot of money from Apple Pay, and has less to make from the other uses for NFC. Apple will likely open up NFC tag reading when they feel that consumer trust and security with NFC and Apple Pay is such that it wont put Apple Pay at risk. Further information here.
--- Update on May 24th 2017 ---
A developer in Greece has hacked the iPhone 6s to get it to read NFC tags via the NFC private frameworks; more info & video. While this isn't a long term solution, it provides some guidance on some outstanding question: Is there enough power in the iPhone's NFC controller to power an NFC tag? Looks like the answer is yes. From initial testing the range is a few cm, which isn't too bad. It might also be the power is tunable; this is being investigated at this time. The implications of this are significant. If the older model phones do have enough RF power for tag reading/writing, then when Apple does open up the SDK it means there will be 100Ms of iPhones that can read NFC tags, vs the case where only the new iPhones could.
At the moment, there isn't any open access to the NFC controller. There are currently no NFC APIs in the iOS 8 GM SDK - which would indicate that the NFC capability will be restricted to Apple Pay at launch. This is our understanding.
Clearly, the NXP chip inside the iPhone 6 is likely to be able to do more so this doesn't mean that additional features (pairing, tag scanning/encoding) will not be added for release or in the near future.
At the moment, Apple has not opened any access to the embedded NFC chip to developers as suggested by many articles such as these ones :
Apple Cripples NFC in iPhone 6, 6+ With Developer Ban from Daily Tech
Apple Restricting Use of NFC Antenna in iPhone 6 and 6 Plus to Apple Pay from Mac Rumors
Apple confirms iPhone 6 NFC chip is only for Apple Pay at launch from Cult of Mac
Apple initially restricts iPhone 6, iPhone 6 Plus NFC chip to Apple Pay from Tech Times
The list goes on. The main reason seems (like lots the other hardware features added to the iPhone in the past) that Apple wants to ensure the security of such technology before releasing any API for developers to let them do whatever they want. So at first, they will use it internally for their needs only (such as Apple Pay at launch time).
"At the moment, there isn't any open access to the NFC controller,"
said RapidNFC, a provider of NFC tags. "There are currently no NFC
APIs in the iOS 8 GM SDK".
But eventually, I think we can all agree that they will develop such API, it's only a matter of time.
The ability to read an NFC tag has been added to iOS 11 which only support iPhone 7 and 7 plus
As a test drive I made this repo
First: We need to initiate NFCNDEFReaderSession class
var session: NFCNDEFReaderSession?
session = NFCNDEFReaderSession(delegate: self, queue: nil, invalidateAfterFirstRead: false)
Then we need to start the session by:
session?.begin()
and when done:
session?.invalidate()
The delegate (which self should implement) has basically two functions:
func readerSession(_ session: NFCNDEFReaderSession, didDetectNDEFs messages: [NFCNDEFMessage])
func readerSession(_ session: NFCNDEFReaderSession, didInvalidateWithError error: Error)
here is my reference Apple docs
The only information currently available is that Apple Pay will be available in ios8, but that doesn't shed any light on whether RFID tags or rather NFC tags specifically will be able to be detected/read.
IMO it would be a shortsighted move not to allow that possibility, but really the money is in Apple Pay, not necessarily in allowing developers access to those features - we've seen it before with tethering, Bluetooth SPP, and diminished access to certain functions.
...but then again, it's been about 5 hours since the first announcement.
I think it will be sometime before we get to see access to the NFC as the pure security side of it like for example being able to walk past somebody brush past them and & get your phone to the zap the card details or simply Wave your phone over someone's wallet which They left on the desk.
I think the first step is for Apple to talk to banks and find more ways of securing cards and NFC before This will be allowed

Is iOS CarPlay API Public? How to Integrate CarPlay?

Is the CarPlay API publicly available?
Where can we find a programming guide or the reference to these classes if it is?
Or will it integrate seamlessly with other APIs like Audio from AVFoundation?
Notes
This question is broad and may be flagged as so but please do not as though there is almost no information on the subject and a lot of people could find it useful at this stage
I live in Switzerland and want to go to Geneva to try out a demo
app that I would write on a Ferrari lol.
Update Oct, 2019:
A couple of years later, Apple opened up their designer guidelines and developer docs on CarPlay. As mentioned in some other comments as well, getting access to developer tools can be done on your mac as well.
Technically, depending on the type of app you want to be compatible with CarPlay, it requires different API's and frameworks. For example:
The CarPlay framework is for use by navigation apps only. If you want to add CarPlay support to your audio app, use MPPlayableContentManager. For messaging apps, use SiriKit’s Messaging-related intents to support reading and sending messages in CarPlay through Siri. For VoIP calling apps, use CallKit with SiriKit’s VoIP Calling-related intents to make and answer audio calls on a CarPlay system.
Legally, however, still the MFi Program requires application and approval by Apple for you to get the appropriate permissions, signing profile etc. in order to deploy it on an actual device. Let alone release it to market. OR... you can try applying for access manually and explain your case.
Lastly, there is also some documentation on how to enable tools and simulator to work with CarPlay. For example, a small excerpt:
CarPlay is supported by default when you run Simulator. However, you should configure the Simulator with extra options when developing a CarPlay navigation app. To enable extra options, enter the following command in Terminal before launching Simulator: defaults write com.apple.iphonesimulator CarPlayExtraOptions -bool YES.
But besides the documentation I can seriously recommend to read what the people at Flitsmeister blogged about on how to enable tooling on your local machine. Also, their road to finally getting approved was apparently tedious and far from smooth (I'm not affiliated with Flitsmeister), even though their use case is based on having lots of users (±1.5mln). Mentioning this to emphasise: CarPlay is apparently still not for the every day developer, just yet.
This question dates of early 2014. Let me update this with a mid 2016 answer:
TL;DR - No, it is not publicly available.
In order to get the tools, documentation, technical specs and even the license itself to develop for (amonst others) Carplay, you need to be enrolled with Apple's MFi Program.
Apple's MFi Program ("Made for iPhone/iPod/iPad") is a licensing program for developers of hardware and software. This is a specific license targeted at manufacturers, mostly of "mass production" units, that has additional benefits over the regular developer accounts for companies. These benefits include hardware components, tools, docs, techsupport and of course the license that you are allowed to develop specifically for these devices and technologies, like Carplay.
The MFi Enrollment FAQ is a decent read that makes everything pretty clear. But before you get your hopes up, do note that -again- it is only available for manufacturers. Like the FAQ states:
Q: Am I eligible to apply for the MFi Manufacturing License if my company does not own a manufacturing facility?
A: No. The MFi Manufacturing License is intended solely for companies that own one or more manufacturing facilities.
There are some exceptions. For example if you're a contractor, or an engineering design firm, that develops MFi accessories for a client (who is a manufacturer).
But basically put, it is not for the average developer and admission is quite strict. This means, in a nutshell, that Apple Carplay is not available to developer for by the, say, 95% of us.
The MusicCarDisplayUI.framework framework is a private framework as of iOS 7.1. Taking a look at the runtime headers of the framework, one can guess why; it's just not ready yet for wide use. Whether Apple will make it public in the future is one's guess.
In the meantime, make sure to open a feature request or directly contact Apple here.
Update: If you wish to have a CarPlay-enabled app, contact Apple using this form.
Just worked on carplay project.
You can find the api documents on apple's developer website.
Like MPPlayableContentManager and MPContentItem.
However only after registered on apple's website for carplay, will apple send you the "Carplay Programming Guide" telling you how to activate the car simulator and what classes to use and how to do things etc.
Take a look at MediaPlayer Framework. There are a bunch of classes in there designed for CarPlay only. For example, MPPlayableContentManager, MPContentItem, etc. Obviously, you won't be able to deploy it via the AppStore without Apple's approval.
Partially since iOS 12.0 : https://developer.apple.com/documentation/carplay
The CarPlay framework is for use by navigation apps only. If you want to add CarPlay support to your audio app, use MPPlayableContentManager. For messaging apps, use SiriKit’s Messaging-related intents to support reading and sending messages in CarPlay through Siri. For VoIP calling apps, use CallKit with SiriKit’s VoIP Calling-related intents to make and answer audio calls on a CarPlay system.

How to submit an app with companion device to AppStore?

Background:
We are developing an application for one of our customer to go along with their device. The application by itself cannot do anything, and must be connected to the device via Wi-Fi in order to function.
Question:
Do we:
just submit the app the standard way, even though there's no way for Apple to really test the functionality of the app?
or
do we need to provide a test device to Apple to really test the functionality of the app? If so, what's the procedure for doing this?
Edit:
Apple's Not-Very-Helpful Response
While we cannot pre-approve apps, we can address compliance questions about specific App Store Review Guidelines or sections of the iOS Developer Program License Agreement (PLA). I understand that this may be a little frustrating and I apologize for any inconvenience this may cause, however, we may only answer specific questions concerning the following resources, unless the app is submitted for review so that we may test the functionality.
App Store Review Guidelines: https://developer.apple.com/appstore/resources/approval/guidelines.html
iOS Developer Program License Agreement: http://developer.apple.com/membercenter/index.action#agreements
There are a few possibilites that have been reported.
One is to submit a video of the app running with your companion device, with a complete walk-through of the app's functionality using that device.
Another is to provide a device emulator as a test mode built into the app (perhaps requiring two devices).
Another is to provide an demo account in the Review notes; and have that account wifi tunnel out to control a remote wifi device at your location, maybe with a webcam aimed at that device and viewable by Apple.
Include proper contact info for that possibility where Apple may want you to send them a sample device for evaluation.
I have the same issue: a third-party device with which the app communicates. Without the device, the app is useless. One screen with one label. I submitted the app to the store, explaining what it does and how it communicates.
The app got approved 5 days later, without Apple asking any questions whatsoever.

Resources