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.

BluKit™ Workbench

Announcing the release of BluKit™ Workbench app to iOS and macOS App Stores!

BluKit Workbench is a utility app that allows you to discover, connect, inspect, sort, filter, and rename your nearby Bluetooth® LE (BLE) devices. BluKit Workbench supports a growing list of Bluetooth GATT Characteristics including Heart Rate, Pulse Oximetry, Cycling Speed, Cycling Cadence, and more.

https://apps.apple.com/us/app/blukit-workbench/id6747599806

“Software Engineer” Position Extinction

Software Engineer Salary Bands
Software Engineer Salary Bands

There are tens of thousands of unfilled software engineering positions across the United States and easily hundreds of thousands of unfilled software engineering positions globally. How preposterous to announce extinction of a position that is so competitive and sought after. Ok, let me explain my position. First, some background.

Decades ago, when software engineering became a recognized discipline within university engineering programs, the graduate with a computer science engineering degree would seek a “software engineer” position. After several years writing software, almost universally a five year minimum, the skilled and “tried” degreed software engineer could expect a promotion to “Senior Software Engineer”. This promotion carried with it an expectation of not just “time in the trenches” but a level of experience, both breadth and depth in the field. It was expected that a Senior Software Engineer would mentor less experienced software engineering peers. The Senior Software Engineer would have experience across the whole software stack including server development experience, database design and architecture, as well as front-end work such as desktop and web development experience. The Senior Software Engineer role carried with it, a level of “fit and fitness” to tackle the hard problems, to ask the tough questions, and be able to arrive at a conclusion on how to solve the problem, or propose a different solution.

Today, as more and more software must be developed to solve the world’s problems, it’s clear that universities are not churning out software engineering professionals fast enough to keep up with the world’s software engineering demands. In the United States, tens of thousands of H1-B Visa applications are applied for, and filled, a large percentage of these are for software engineering positions. The basics of economics, supply and demand drive the world’s software engineers to the US shores.

With that background, let me explain my outlandish blog post title “‘Software Engineer’ Position Extinction.” Truly the need for more software engineers has never been greater. Over the last decade, with the rise of the smart phone and giant shift in how consumers access the internet, the shift from desktop to smart phones, competant mobile developers have become highly sought after. With a shortage of supply and such a steep demand curve, the economics mandate that the cost of acquiring such a software engineer will indeed rise. Salaries for software engineers have probably risen faster than most other industries. In 1992 the average starting salary for a software engineer graduating with a BS in Engineer would be between $28,000 and $32,000. Today it closer to $80,000-$100,000+.

Well established companies rely on Human Resources to make sense of salaries, positions, etc. HR uses a tool called salary bands (or range) to bring order and some sense of fairness to the sticky area of salaries and compensation. For example, a Software Engineer I may have a salary band of $80,000 to $95,000 while a Software Engineer II might have a salary band of $90,000-$105,000.

With the meteoric rise of software compensation in the late 1990s with the rise of the internet and surge in demand, these salary bands were adjusted significantly upwards. After the dot-com rise and collapse things stayed relatively stable for a short few years and then in 2007, Apple introduced the iPhone and changed the landscape of computing forever. This warranted a shift in salary bands but none came.

Instead, what I’ve witnessed is position extinction. Within twelve to eighteen months of graduating with a bachelor’s in engineering, the high demand for software engineers, a robust economy, and the shortage of software graduates, will allow the new software professional to easily outgrow the Software Engineer salary band in all but the most static industries. With many new software engineering candidates receiving multiple salary offers, HR is limited in its options to attract the candidate. While the experience of the candidate may easily align with well established expectations, the salary band no longer fits the competitive landscape. Thus HR is faced with two choices, find another candidate or bump the candidate into the next higher salary band. Software Engineer band is a very short rung on the salary ladder to Senior Software Engineer, even if the candidate’s skills do not match the new position.

Technical Interview Trends

source code

Over the past year or so, I have observed a growing trend used by hiring companies early in their interview process of computer professionals. As in the past, the recruitment / interview process begins with an initial contact by a recruiter, or with a job seeker visiting a job board. Once the job seeker expresses interest in the position by clicking the online job lead, the job seeker is presented with a form in order to upload a résumé, or complete and submit an online job application. This has been the norm for many years. 

This leads to the next step in the interview process: further narrowing the list of possible candidates. This step is where I see the most change taking place, and this change, I believe, will affect the future of high tech job interviewing: Assuming the candidate’s résumé is determined algorithmically to be a goodmatch, and the candidate has shown interest in the position, the candidate will receive an email with instructions to complete a technical assignment, or an online technical challenge. The self-paced technical assignment could be short or long, but typically ranges from a couple of hours to a couple of days. In the case of an online technical challenge, these are typically time-boxed between 30 minutes and one hour in length, and focus on technical problem solving, and algorithms. Once the technical challenge is completed, candidates should expect their submission to be analyzed by software algorithms, unit tests, etc. Unsuccessful candidates will receive computer-generated decline responses, while successful candidates will receive instructions for the next phase in the interview process. While the technical problem solving, and algorithms interview style is not new to computer professionals, especially at large comanies like Amazon, Apple, Facebook, Google, Microsoft and Yahoo, the widespread use of online assessment tools and automation of results is. 

The high tech interview process is changing rapidly and successful job seekers must adapt. Your online professional profile and résumé might get you into the interview funnel, but your ability to complete increasingly complex technical challenges in time constrained, online formats, will be required to move you through the interview pipeline. Time to brush up on your computer science fundamentals!

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