BluKit™ Framework 2.0

BluKit Framework

Today we are proud to announce the release of BluKit™ Framework version 2. Version 2 introduces two big improvements over version 1:

  • Virtual Peripherals
  • API Alignment with CoreBluetooth Framework

Virtual Peripherals

As announced in the BluKit™ Workbench App 2 blog post, Virtual Peripherals are an exciting new feature in BluKit. BluKit Workbench App version 2 is the primary App where Virtual Peripherals can be created and exported to a JSON file. The Virtual Peripheral helps software developers model physical Bluetooth peripherals. BluKit Framework allows software developers to import and develop software against this Virtual Peripheral, even writing unit tests and leveraging Xcode Simulators!

Limitations of Apple’s CoreBluetooth Framework

Many years ago, Apple partnered with the Bluetooth SIG and provided software developers with a software Framework (or API) to facilitate integration of applications with Bluetooth. This Framework is known as CoreBluetooth Framework. With CoreBluetooth Framework and Bluetooth Peripherals, software developers could unlock a whole new class of apps that could interact with thousands of different Peripherals. As years past and more Bluetooth Peripherals emerged including many devices supporting health and fitness as well as Home automation, the demand for quality apps and great user experiences grew.

Unit Testing Leads to Better Quality Software

As any seasoned software developer knows, writing the right unit tests that are repeatable can save countless hours of fixing bugs in released code. A whole new generation of technology emerged to meet this need in the form of CI/CD or Continuous Integration and Continuous Delivery. Underlying these new systems is the premise that with CI/CD comes more timely, predictable, and better quality software. More timely doesn’t equal better quality, so in order to achieve this, writing unit tests to test the important aspects of software became the norm in many development shops. Unit tests are intended to focus on a particular routine or feature in the software and provide simple, repeatable tests that can be run efficiently and quickly with every release. Combined with a CI/CD system, many software companies will run thousands of unit tests with every software commit or even pull request. This allows bugs to be caught very early in the software delivery cycle. They are much easier to fix and much less costly when caught before software is released to the public.

Unit Testing Bluetooth Interfaces

As discussed above, while CoreBluetooth provides a proven API for the software developer building apps for the Apple App Store to interface with Bluetooth Peripherals, CoreBluetooth has limitations specifically around unit testing and Xcode Simulators. So what can a software developer do to improve app quality in the area of Bluetooth integration? Simply put, BluKit Framework 2 introduces support for using Virtual Peripherals with Xcode Simulators. Software developers can write unit tests against a Virtual Peripheral modeled after the real Bluetooth Peripheral. BluKit Framework allows Virtual Peripherals, Xcode Simulators, and Unit Tests to come together to support app quality. Using a CI/CD system with BluKit Framework, Virtual Peripherals, Xcode Simulators, and Unit Tests, software delivery teams can ensure consistent quality and delivery of software including code that interfaces with Bluetooth peripherals!

Simple Migration from CoreBluetooth to BluKit Framework

In version 2, BluKit Framework APIs have been updated to align very closely with CoreBluetooth. Where CoreBluetooth classes begin with “CB”, BluKit drops the “CB”. For example, in CoreBluetooth, the Peripheral class is “CBPeripheral”. In BluKit, it is simply “Peripheral”. This allows software developers to migrate from CoreBluetooth Framework to BluKit Framework version 2 very quickly. In addition, BluKit Framework version is available at the Swift Package Index as BluKit Package for simple integration with Xcode projects as a Swift Package.

BluKit Framework Example App

To see how easy BluKit Framework can be used to build quality Bluetooth apps with Unit Testing and Virtual Peripherals, please see BluKit Example App 1 Github Repo.

Licensing BluKit Framework

To explore licensing BluKit Framework for your own app development, please Contact Sales using the Contact form on our web page.

BluKit™ Workbench App 2.0

BluKit Framework

BluKit™ Workbench App version 2 marks are major milestone release! Improving on a solid 1.0 release is always a challenge but we did just that in version 2. In version 2, we strived to add features that would improve the Bluetooth development experience of software developers. To say this release is developer focused would be an understatement.

API Contracts between Client and Server Teams

Very often in software development teams, both the client facing software and the server side software are written in parallel as the product owner works to push out new App features. This of course requires coordination between the client and server teams, it adds release cycle pressure, and of course testing pressure. This is all too familiar to seasoned software developers! How does the client team write software to interface with the server when the server API is not published, tested, or even finished? A contract or Application Programming Interface (aka API) between the server side and client side software must be ironed out first to avoid delays, bugs, and other problems. Once the API is agreed upon, only then can both client and server software teams work successfully in parallel.

Bluetooth Peripheral as an API Contract

How does this relate to App support of Bluetooth peripherals? Just as client and server software development teams must work in parallel, so also must software developers building Bluetooth support into their apps. In this scenario, most often the client side is the App and the server side is the physical Bluetooth hardware. So, both teams must agree upon what data will be read and what data will be written between the App and the physical Bluetooth hardware (aka peripheral). When is the data available to be read and when is the data able to be written. All of this formality makes up the API contract between the app and hardware teams.

Virtual Peripherals

Ok, so how does all this client / server API contract discussion relate to version 2 of BlueKit Workbench? So glad you asked! At the forefront of features introduced in version 2, is an exciting new software developer feature: Virtual Peripherals! What is a virtual peripheral? Essentially it behaviors like a real physical peripheral but it is not physical. It is the representation of a physical peripheral, but in software. In other words, a Virtual Peripheral encapsulates the data that will be shared between the App and the Peripheral. In BluKit Workbench App version 2, a Virtual Peripheral can be created by recording data from a real Bluetooth Peripheral. After recording the data, it can be exported as a Virtual Peripheral. The following Bluetooth peripheral data can be recorded in real time, and exported to a JSON file:

  • Peripheral
  • Services
  • Characteristics
  • Descriptors
  • Advertisement Data
  • RSSI Signals
  • Characteristic Notify/Indicate values as Data

The exported JSON Bluetooth peripheral data can be inspected, and even modified! Import the valid JSON file into BluKit Workbench. The new “Virtual Peripheral” appears as another discovered Bluetooth peripheral. Inspect, Connect, and interact with the Virtual Peripheral just like a real peripheral! In this way, the application software developer (client side) working to interface with a real physical Bluetooth peripheral can begin work even though the physical Bluetooth peripheral may not be available or ready for App connections.

BluKit Workbench – Apple App Store

BluKit Workbench App is available in the Apple App Store. Learn how it can accelerate your software development efforts with Bluetooth integration: https://apps.apple.com/us/app/blukit-workbench/id6747599806

BluKit™ Framework

Announcing the release of BluKit™ Framework for Apple Developers!

What is BluKit™ Framework?

BluKit Framework is a cross-platform Xcode framework available for commercial licensing by companies integrating Bluetooth® into their iOS, iPadOS, and macOS apps. Software Engineers using BluKit Framework will:

• Shorten Bluetooth development time
• Improve Bluetooth integration
• Avoid costly Bluetooth bugs

BluKit Framework is written entirely in Swift, but also available for legacy Objective-C integration. BluKit Framework builds on top of Apple’s CoreBluetooth framework and supports a growing list of Bluetooth GATT Characteristics including Heart Rate, Pulse Oximetry, Cycling Speed, Cycling Cadence, and many more.

To illustrate how robust BluKit framework is, we built our own multi-platform app, BluKit™ Workbench using BluKit. Available on iOS and macOS App Stores.

Cleaning up the (app) store

My original post is here on LinkedIn.

Apple is finally making good on their promise to clean the (app) store shelves and it’s coming sooner than you think. January 1st is the deadline Apple has given many app developers to clean up their own mess. What’s interesting about that date is how the Apple app review process mostly grinds to a halt after December 22 when most of Apple (except retail) shuts down for the holiday break.  What I also find interesting (and refreshing) is that Apple is broadening the scope of what they consider as candidates for removal or rejection. Not only are they targeting template-created apps from commercial app-generation tools, but also apps which are low quality, or even white-labeled apps.  What is a white-labeled app? A good example of this is a little league sports team app that is customized by changing basic attributes like app icon, color, or labels for each team or league. Apple has decided to push app creators to up their game. Apple wants well designed and developed apps offering value to the market. Quality over quantity.  I’m looking forward to the app store landscape ahead. What are your thoughts?

App Store Review Guidelines