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.
Related
For iOS, is there any way to debug an apple app? Just to see what it does behind the scenes? I want to debug the apple music app.
I am asking this because I want to know how is apple able to use the "heart" button lock screen control in iOS 9. I can't seem to find any documentation on this. I understand this is reverse engineering and this may not be allowed.
Reverse engineering is a violation of the iOS SOFTWARE LICENSE AGREEMENT.
(d) You may not, and you agree not to or enable others to, copy (except as expressly permitted by this
License), decompile, reverse engineer, disassemble, attempt to derive the source code of, decrypt,
modify, or create derivative works of the iOS Software or any services provided by the iOS Software or
any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable
law or by licensing terms governing use of open-source components that may be included with the iOS
Software).
That being said; you can find in this talk by Conrad Kramer, informations on tools for iOS reverse engineering like Charles, cycrypt, IDA and dumdecrypted .
Note that many of those tools are only available for jailbroken devices.
Happy hacking :)
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.
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
I am trying to build an iOS app which would communicate with another non-apple device via bluetooth. It would be a Bluetooth Stereo Transmitter which uses the bluetooth A2DP-profile which is supported by apple :
http://support.apple.com/kb/HT3647?viewlocale=en_US&locale=en_US
I have read tons of articles and pages. I have many unanswered questions and hope to recieve some answers and write something that will help me and others in future work with iOS and bluetooth.
Evaluating the available bluetooth connection options
Here's a list with possible approaches and informations I found. Please feel free to answer/edit anything that is not correct.
Edited from http://www.pocketmagic.net/2012/07/bluetooth-and-ios-use-bluetooth-in-your-iphone-apps/ :
A) Enroll in the made for iPhone/iPod/iPad (MFi) program. Details on costs are not available, but this is not for the small development companies, barely selling a few licenses.indicate costs depending on project, and starting numbers somewhere at 10K USD. Not really an option IMO, as the costs involved and trouble getting certified are ridiculously high, for something so basic and simple such as building a Bluetooth application. I have found a Bluetooth stereo transmitter with bluetooth version 2.1 (Class II). I can not find if the device is MFi compliant.
Based on this article :
Existing bluetooth device and Apple MFI
Q1: How can I be sure or find out if the device is Mfi compliant?
Q2: If the device is Mfi compliant will I be able to pair it with the device in the settings option?
B) CoreBluetooth framework, currently usable only with Low Energy Bluetooth 4 devices. Since these are not largely spread this is not really an option. You won't be able to connect to standard headsets, keyboards, or other non-Bluetooth 4 devices.
Q3: Will I need to pair the non-apple bluetooth device with my iPad (in settings) to use the CoreBluetooth framework?
I am asking beacuse I have no experience with iOS and bluetooth and beacuse my budget is low, so I dont want to waste money buying stuff I will not be able to use for development.
C) GameKit framework, this allows some basic Bluetooth functionality, such as finding nearby devices and establishing a serial communication link, but it only intended for use between iOS devices. So Android plus iPhone via GameKit is a no go.
D) Private APIs. There is a BluetoothManager framework, in the private APIs, inside the SDK. This can be used to achieve the proposed task, but you won't get your App approved on Appstore, as private API's is not allowed by Apple. Since this is so convenient, and working so nice, almost like the real thing Apple didn't want to include.
Q4: Can I use private APIs within the iOS Eneteprise program and distribute my apps since there is no App store approval process?
Q5: Does anyone know some more private APIs I could use beside bluetoothManager framework?
E)Jailbreaking and using Ringwald's BTStack. Jailbreaking = rooting = freedom, probably the best way to go . But this places you so far away from Apple's guidelines, and the Appstore itself. So better decide what your project is all about, and who your users will be.
Q6: For bluetooth I need CoreBluetooth Framework. What framework do I need to import if I want to use wifi communication?
Thanks for any help :).
I'm working on my senior engineering design project and I need your help! For this I have my iPhone app receiving images from a external camera circuit, which I built.
To interface my iPhone app to the camera circuit, I have looked into the following approaches:
Build a bluetooth module on the camera circuit, to transfer images to the iPhone
Use Eye-Fi SD card to transfer images to my app somehow! link:http://www.eye.fi/products/iphone
Build a circuit, to make a wired connection to the iPhone with the 30-Pin dock connector
Here are the problems I'm facing with each of these. My actual questions for you guys are highlighted in BOLD:
The iOS BlueTooth framework (4S only), only supports Low Energy Devices. Looking at the the modules out there like this one, I'm doubting it will work for image transfer, which seems to be a bulky task for low energy bluetooth. I know there are jailbreak apps on the cydia store, which do regular bluetooth transfers, but I was unable to find those private APIs for such a task. (NOTE: I'm making this app for my purposes, so feel free to suggest any private/unofficial APIs). Question#1: How can I interface to a regular bluetooth device (not another iPhone) and transfer data?
EYE-FI card sounded amazing as a consumer because the company has their proprietary iPhone app to transfer the images from the EYE-FI SD card. Problem is I can't figure out how to easily interface with the EYE-Fi card in my code. I researched the iOS CFNetwork framework, but haven't had any luck. Question#2:How can I interface with the EYE-FI card in my app?
Building a circuit seems simple enough with this development board, but I read somewhere that the iPhone may not recognize an "un-registered" accessory. I have a developer license but not a MFi licence. Question#3: Do I need to be registered as a MFi developer to create and use this external accessory in my App for my own purposes???
You might try setting something up through a serial port since joining the MPi program is prohibited for individuals. You could possible use a connector like this one http://www.amazon.com/neXplug-Ultra-Small-Micro-Adapter/dp/B0055PCVDO/ref=sr_1_1?ie=UTF8&qid=1339309918&sr=8-1
The Apple website recommends individuals/hobbyists to use " recommend that you use a third-party solution which will allow you to connect iOS devices to serial devices and to write iOS apps that communicate with these serial devices" (from mfi.apple.com/faq).
I am also working on an external camera that can hook to the iphone/ipad. I will be using a serial port in order to get around the MFi requirement for external iphone/pad devices. Trying to use bluetooth is too complicated and the data stream isn't big enough for pictures. the wired version will work much better.
I hope this helps and that your college term and project are not already finished. Best of luck.
As T Reddy has already mentioned, if you want to create hardware the interfaces with external hardware framework, you have to sign up with the Apple MFi program which you, as an individual, can not do.
I'm not sure of how the Eye-Fi system works but it sounds to me that it basically syncs the images to their server and once you download their Apple App, the app can sync the photos for you.
Whether you are using Bluetooth or the 30-pin connector, there is no way to interface to an external device unless that device is MFi compliant and a part of the MFi program. I suggest you try the following options to solve this delimma--
If this is a "Senior Project" at some University, see if your University is part of MFi. Apple will not let individuals join the program, so if you are going to gain access, you have to access it through another organization or, possibly, an educational institution. I don't know if Apple has worked with schools in this regard, but you never know. It might be possible.
If your school isn't in the MFi program then you may want to consider re-writing your application for an Android device. Android devices are not locked down like iOS devices, so that may be a more reasonable approach.
I hate to bring bad news but circumventing these hardware restrictions on an iOS device is excessively prohibited. Your options are quite limited and none of them are probably what you either want or need to hear.