Make Your Own BLE-Enabled IOS App From Scratch

December 4, 2021 by Orlando Hoilett 20 Comments

Even those readers who are most skeptical of Apple products will like this Bluetooth Low Energy (BLE)-enabled iOS app tutorial from [Akio].

With everything being “connected” these days smartphone applications are of course a ubiquitous part of our existence. We’ve seen plenty of examples connecting your Bluetooth-enabled projects to an Android device, but comparatively fewer tutorials for connecting to iOS devices. This mostly has to do with Android’s much larger market share and also Android’s more open-source friendly business model. Nevertheless, if you do much IoT development either as a hobby or professionally, then you probably find yourself interacting with Apple devices more than you like to admit.

[Akio’s] app is essentially updating a chart, in real-time, with data read from an Adafruit nRF52832 Feather board. He then walks you through all the basics of creating a user interface (UI) using Apple’s Storyboard interface, a simple drag-and-drop scheme similar to something you’ve probably used in many other contexts. [Akio] shows readers how to add buttons for allowing users to interact with the app, labels for displaying data to the user, as well as walks you through Apple’s odd methodology of connecting UI elements to code using IBAction and IBOutlets. The highlight of his tutorial is showing readers how to add charts to their iOS apps which seems to take a few more steps than you might imagine.

[Akio] does a really good job detailing all the relevant functions so that readers will hopefully understand what each piece of the code is doing. And we really enjoyed him adding individual video tutorials for some of the trickier programming steps. He also readily admits that some folks may opt to develop their UI exclusively in code as opposed to the Storyboard but he argues that the Storyboard is still important for beginners and is really handy when the UI is fairly simple.

Of course, in true open-source fashion, [Akio] provides all his code on his GitHub repository so you can clone the repo and run the code yourself as well as credit some of the resources he used while making his app. Two things we really love to see. Hopefully, [Akio’s] tutorial will make connecting to iOS devices seem much less onerous than it once was.

Listening To An IPhone With AM Radio

September 18, 2020 by Danie Conradie 38 Comments

Electronic devices can be surprisingly leaky, often spraying out information for anyone close by to receive. [Docter Cube] has found another such leak, this time with the speakers in iPhones. While repairing an old AM radio and listening to a podcast on his iPhone, he discovered that the radio was receiving audio the from his iPhone when tuned to 950-970kHz.

[Docter Cube] states that he was able to receive the audio signal up to 20 feet away. A number of people responded to the tweet with video and test results from different phones. It appears that iPhones 7 to 10 are affected, and there is at least one report for a Motorola Android phone. The amplifier circuit of the speaker appears to be the most likely culprit, with some reports saying that the volume setting had a big impact. With the short range the security risk should be minor, although we would be interested to see the results of testing with higher gain antennas. It is also likely that the emission levels still fall within FCC Part 15 limits.

Continue reading “Listening To An IPhone With AM Radio” →

Apple HomeKit Accessory Development Kit Gets More Accessible

December 27, 2019 by Kerry Scharfglass 6 Comments

Every tech monopoly has their own proprietary smart home standard; how better to lock in your customers than to literally build a particular solution into their homes? Among the these players Apple is traditionally regarded as the most secretive, a title it has earned with decades of closed standards and proprietary solutions. This reputation is becoming progressively less deserved when it comes to HomeKit, their smart home gadget connectivity solution. In 2017 they took a big step forward and removed the need for a separate authentication chip in order to interact with HomeKit. Last week they took another and released a big chunk of their HomeKit Accessory Development Kit (ADK) as well. If you’re surprised not to have heard sooner, that might be because it was combined the the even bigger news about Apple, Amazon, the Zigbee Alliance, and more working together on more open, interoperable home IoT standards. Check back in 2030 to see how that is shaping up.

“The HomeKit ADK implements key components of the HomeKit Accessory Protocol (HAP), which embodies the core principles Apple brings to smart home technology: security, privacy, and reliability.”
– A descriptive gem from the README

Apple’s previous loosening-of-restrictions allowed people to begin building devices which could interact natively with their iOS devices without requiring a specific Apple-sold “auth chip” to authenticate them. This meant existing commercial devices could become HomeKit enabled with an OTA, and hobbyists could interact in sanctioned, non-hacky ways. Part of this was a release of the (non-commercial) HomeKit specification itself, which is available here (with Apple developer sign in, and license agreement).

Despite many breathless mentions in the press release it’s hard to tell what the ADK actually is. The README and documentation directory are devoid of answers, but spelunking through the rest of the GitHub repo gives us an idea. It consists of two primary parts, the HomeKit Accessory Protocol itself and the Platform Abstraction Layer. Together the HAP implements HomeKit itself, and the PAL is the wrapper that lets you plug it into a new system. It’s quite a meaty piece of software; the HAP’s main header is a grueling 4500 lines long, and it doesn’t take much searching to find some fear-inspiring 50 line preprocessor macros. This is a great start, but frankly we think it will take significantly more documentation to make the ADK accessible to all.

If it wasn’t obvious, most of the tools above are carefully licensed by Apple and intended for non-commercial use. While we absolutely appreciate the chance to get our hands on interfaces like this, we’re sure many will quibble over if this really counts as “open source” or not (it’s licensed as Apache 2.0). We’ll leave that for you in the comments.

Google Creates Debuggable IPhone

November 3, 2019 by Al Williams 8 Comments

Apple is known for a lot of things, but opening up their platforms to the world isn’t one of those things. According to a recent Google post by [Brandon Azad], there do exist special iPhones that are made for development with JTAG ports and other magic capabilities. The port is in all iPhones (though unpopulated), but is locked down by default. We don’t know what it takes to get a magic iPhone, but we are guessing Google can’t send in the box tops to three Macbook Pros to get on the waiting list. But what is locked can be unlocked, and [Brandon] set out to build a debuggable iPhone.

Exploiting some debug registers, it is possible to debug the A11 CPU at any point in its execution. [Brandon’s] tool single steps the system reset and makes some modifications to the CPU after key instructions to prevent the lockdown of kernel memory. After that, the world’s your oyster. KTRW is a tool built using this technique that can debug an iPhone with a standard cable.

Continue reading “Google Creates Debuggable IPhone” →

Apple Lightning Video Adaptors Run IOS, Dynamically Loaded

July 30, 2019 by Jenny List 28 Comments

Apple has for a very long time been a company that ploughs its own furrow when it comes to peripherals, with expensive proprietary hardware being the order of the day over successive generations of its products. One of its current line of proprietary interfaces is the Lightning connector, best thought of as an Apple-only take on the same ideas that the rest of the world knows as USB-C. There are a whole host of white dangly peripherals that can be hung from your iDevice’s Lightning port, including a pair of display adaptors that allow them to drive an HDMI or VGA monitor. [Lisa Braun] has subjected one that had failed to a teardown, and her analysis gives some insight into the way Apple creates its peripherals.

Where you might expect these to contain mostly the equivalent of a graphics card, in fact they have a fully-fledged SoC of their own that runs its own OS with the same Darwin kernel as its host. Unexpectedly this is not held upon the adapter itself, instead it is shipped with iOS and loaded dynamically. Thus the file containing it can be retrieved from iOS and unpacked, leading to some interesting analysis. In a fascinating twist for those of us unused to Lightning’s internals, it’s revealed that the device can be driven from a USB port with the appropriate cobbled-together adapter, allowing a full-size MacOS device to interrogate it. This many not be news to readers with a long memory though, we’ve told you in the past about reverse engineering the Lightning connector.

Open Source Computer Controlled Loom Weaves Pikachu For You

June 18, 2019 by Helen Leigh 17 Comments

The origin story of software takes us back past punch card computers and Babbage’s Difference Engine to a French weaver called Joseph Marie Jacquard. Jacquard created a way to automate mechanical looms, giving weavers the ability to change a loom’s pattern by simply switching punch cards. This invention not only made it possible to produce detailed fabrics in a vastly simplified way, it was an extremely important conceptual step in the development of computer programming, influencing Babbage’s development of the Analytical Engine amongst many other things.

So, when [Kurt] saw his son’s enthusiasm for weaving on a simple loom, he started thinking about how he could pay homage to the roots of software by designing and building an open source computer controlled loom. He knew this was going to be difficult: looms are complex machines with hundreds of small parts. [Kurt] wrestled with wonky carriage movements, cam jams, hook size disasters and plenty of magic smoke from motor control boards. After a year and a half of loom hacking he succeeded in making a 60 thread computer controlled loom, driven by an iPhone app using Bluetooth.

As well as writing up the story of this build on his blog, linked above, [Kurt] has also has made all of his design files, PCB layouts, firmware and code available on GitLab.

We’ve featured a few weaving hacks over the years, including this cheap, simple 3D printable loom and a Jacquard inspired bitmap display.

Fun, informative build video after the cut.

Continue reading “Open Source Computer Controlled Loom Weaves Pikachu For You” →

Does Library Bloat Make Your Smartphone App Look Fat?

December 18, 2018 by Tom Nardi 53 Comments

While earlier smartphones seemed to manage well enough with individual applications that only weighed in at a few megabytes, a perusal of the modern smartphone software store uncovers some positively monstrous file sizes. The fact that we’ve become accustomed to mobile applications requiring 100+ MB downloads on what’s often a metered Internet connection in only a few short years is pretty crazy if you stop to think about it.

Seeing reports that the Nest app for iOS tipped the scales at nearly 250 MB, [Alexandre Colucci] decided to investigate. On his blog he not only documents the process of taking the application apart piece by piece to find out just what’s eating up all that space, but lists some potential fixes which could shave a bit off the top. Even if you aren’t planning a spelunking expedition into your pocket supercomputer’s particular variant of the Netflix app, the methodology and tools he uses here are fascinating in their own right and might be something worth adding to your software bag of tricks.

By passing the application’s files through a disk usage visualizer called GrandPerspective, [Alexandre] immediately identified some rather large blocks of content. The bundled Apple Watch version of the app takes up 23 MB, video and audio used to walk the user through the device setup weigh in at 22 MB, and localization files for various languages consumes a surprising 33 MB. But the biggest single contributor to the application’s heft is the assorted libraries and frameworks which total up to an incredible 67 MB.

Of course the question is, how much of it is really necessary? It’s hard to be sure from an outsider’s perspective, but [Alexandre] notes that a few of the libraries used seem to be redundant or obsolete. In some cases this could be the result of old code still lurking in the project, but the four different libraries used for user tracking probably aren’t in there by accident. It also stands to reason that the instructional videos could be offloaded to something like YouTube, so that only users who need to view them have to expend their bandwidth on it.

Getting a little deeper into things, [Alexandre] notes that some of the localization images appear to be redundant. As a specific example, he points to the images of the Nest itself displaying Fahrenheit and Celsius temperatures. While logically this should only be two image files, there are actually eight copies of the Celsius image, each filed away as language-specific. These redundant localization images could easily be stripped out, but with gains measured in only a few hundred kilobytes, it probably wasn’t considered worth the effort during development.

In the end there’s really not as much bloat as we might like to believe. There were some redundant files, maybe a few questionable library inclusions, and the Apple Watch version of the app could surely be separated out. All together, it might get you a savings of 30 – 40%, but still not enough to bring it down under 100 MB.

All signs point to the fact that modern smartphone software development is just a lot more burdensome than us hackers might like. Save for projects looking to put control back into the hand’s of the users, it looks like mobile operating systems aren’t going to be slimming down anytime soon.