As a software engineer, it is really exciting to work at the crossing of software and hardware. It is also a trend on the rise — with the spread of smart things (IoT) and increased use of AI as a differentiator for hardware (think Google’s Pixel Buds), understanding the connection between a hardware device and an iOS app can be a nice to have skill. It’s not something really common as an iOS developer, so I was glad to have this opportunity at Prynt. builds a portable, easy-to-use printer for iPhone, you plug it in your iPhone and you can instantly print your pictures and see them video-animated in the Prynt app (think turning your smartphone into a Polaroid camera mixed with ). Prynt Harry Potter-style features So how do we connect to a hardware device? First, you need to have a prototype board with the required hardware (at least a lightning connector). Then the goal is just to do a simple project, that can light a LED for instance, or compute an addition. Let’s code! Apple provides a great in Objective-C, don’t forget to turn on in the capabilities of your target. This project demonstrates the basic use of . The protocol used to communicate with your accessory is iAP2 ( ). It’s the same protocol on Bluetooth. sample project Wireless Accessory Configuration ExternalAccessory.framework iPod Accessory Protocol 2 You have 3 main classes: : responsible to give you the list of accessories (plugged on the lightning port, via bluetooth etc..) your app can connect to. EAAccessoryManager : an accessory connected to your iPhone ( not necessarily connected to your app). It has property like name, manufacturer, serial number etc.. EAAccessory : Responsible for the connection and exchanging data with the accessory EASession Here is how to create a session and set up its output and input stream: accessory = .shared().connectedAccessories.first! session = (accessory: accessory, forProtocol: protocolString) session.outputStream?.delegate = session.outputStream?.schedule( : .main, forMode: .defaultRunLoopMode) session.outputStream?. () session.inputStream?.delegate = session.inputStream?.schedule( : .main, forMode: .defaultRunLoopMode) session.inputStream?. () let EAAccessoryManager let EASession self in RunLoop RunLoopMode open self in RunLoop RunLoopMode open The and inherit from . Basically you will write data on the which your hardware device can read and it can send you data on the , which will be read by your app. outputStream inputStream [NS]Stream outputStream inputStream Note: The output & input streams are scheduled on the main thread. We tried to scheduled them on a background queue, it may work for a simple project, but in the end we didn’t received / send all the data. I recommend to schedule them on the main thread and dispatch the parsing and serialization on background queues. Data exchange between your app and your device This is how you write and read bytes: session: bytesToWrite : [ ] = [ , , ] session.outputStream?.write(&bytesToWrite, maxLength: bytesToWrite. ) bufferSize = buffer = [ ](repeating: , : bufferSize) session.inputStream!.hasBytesAvailable { session.inputStream!.read(&buffer, maxLength: bufferSize) } var EASession // Write bytes on the output buffer var UInt8 0x00 0x01 0xFA count // ---------------------------------- // Read bytes on the input buffer let 16 var UInt8 0 count if // buffer contains maximum 16 bytes read on the buffer At this point it may not work on the first time, you are sending data, don’t really know if your hardware received them. Your app is supposed to get some data, but nothing on the input stream… You need to investigate, to understand why your data are not sent or retrieved. Depending on your project you may need a and an ATS to analyse the bytes transmitted between the iPhone and your hardware device in real time. Basically you will have access to all the bytes that are going from and to the lighting port in real time. I found really useful to read, parse (with regex) and understand all the data sent and received. Beagle Hex Fiend If your cables between the ATS, the beagle, your mac, iPhone and the hardware board are too long or of poor quality, it may not work (seriously, we had this problem with too long cables). About Code Quality… Sending and receiving bytes can become a nightmare if you don’t have a good specification and you stick to it. Organising bytes as is really helpful, here is how we organised our data exchange at Prynt: frames : A fixed size amount of bytes. It’s main goal is to transmit a command. Header : (Optional) Data you want to send, it can be a firmware update, a photo to print, the battery level, status of the hardware etc… Payload : + Frame Header Payload : We use the first two bytes to verify we’re reading the beginning of the header. In our case we arbitrary choose 0x0F and 0xF0 for the sync bytes, but you can choose any value Sync Bytes : Just a counter, you increment each time you send a new command, it helps to check if a frame is missing Packet Number : The information you want to ask / send (Print a picture, get the status, get the battery level etc…) Command : Useful if you want to be sure your payload or header as not been altered. CRC (Cyclic Redundancy Check) Having bytes organised as a frame is easier to parse, one thing that is helpful for us having our model made of UInt8 (= a byte), like for instance, the : BatteryLevel { low = normal = high = notInitialized = } data: battery = (rawValue: (data[ ])) ?? .notInitialized : enum BatteryLevel UInt8 case 0x01 case 0x02 case 0x03 case 0xFF let Data // data read from inputStream // Here is how we parse it if the battery information is on the 3rd byte of data. let BatteryLevel 3 And of course, the parsing and serialization of those data should be well tested. Conclusion Playing with hardware is really fun for several reasons, your code has a material impact on something else, something physical, I remembered the feeling the first picture was printed with our Prynt Pocket, it was breathtaking. One thing I really enjoyed is dealing with data from a lower level perspective (rather than a REST API). It was fun to learn! But the MFi process might be complicated for a side project, you need to have a company and the tools can be costly. For a side project, a great way to play with hardware is via Bluetooth and with a Raspberry Pi. If you like this article or have any questions, I’ll be happy to read them in the comments! Icon credit
