This morning, Apple approved my enrollment in the developer program. However, I didn't waste the time until that point -- instead, I devoured all of the official documentation on app design provided by Apple. That led me to some drastic changes in direction:

1. I will try to use (where it makes sense) standard Apple design patterns and make the app feel 100% native.
   1. This includes trying to use standard theming because the "glass" appearance is too good not to use.
2. Try to get users right into the action. No onboarding process, if possible.

So, although I said I would start with onboarding screens, I want to avoid that and instead get right into the meat of the main interface: Your Rig.

Side note: the provisioning profile issue was that I needed to magically know to look on the other side of the laptop notch to discover the "Window" menu where half of Xcode's functionality is hidden. Inside that menu, the "Devices" window was what I needed.

Jumping right in​

I want it to feel completely intuitive and straightforward to use this application while maintaining all the power needed for the prosumer-level features. The app's main screen will consist of the controls for the receiver -- and, eventually transceiver. To start with, I'm making a bunch of placeholder controls. I'll cover most receivers' features and the means to control them, though the interface moves beyond controlling an SDR or other radio.

The controls for the radio are secondary to the app's primary purpose. This app is about listening to and (once implemented) transmitting on the radio to communicate - the purpose of amateur radio itself. For this reason, I want to avoid making the standard controls of radio the primary point of interaction. They should be handled automatically. The user usually interacts with the panadapter display.

It's fun to build a UI like it's Lego. Though Xcode doesn't benefit from it - how am I supposed to know about the plus sign on the top right of the window and determine it's for adding stuff to the preview window nested 5 levels in? Xcode, I'm telling you as a friend: having multiple windows with distinct toolbars is okay.

I quickly ruled out the "split window" - there's no need for a persistent browser. The app should avoid switching contexts, and using a browser is a significant way that occurs.

I played around in Xcode a bunch and determined that I'd like to try a designing app for mockups before bothering with implementation. I got some hands-on experience, and I know what components I want and what things I will need to build myself. There's a bunch that I will need to make myself.

In the next post, I'll cover the overall layout of the main app screen.

I've got good news or bad news, depending on what devices you use. Hamadapter has big plans, and it needs some strong platform support. I need access to the GPU and strong support for running ML models. And I want to do that on-device because that's a better user experience and a cheaper experience for the developer! That means Apple silicon and the Apple developer platform are essential. Initially, I was looking at React Native, which I use at work. However, I want to make this as unrelated to my work as possible. That ensures I stay within IP ownership boundaries while doing this hobbyist work. React Native also leans heavily on Objective-C; it's something that I'm not interested in writing adapters and working around old build systems to make it work with Swift. Instead, I will go with the standard pattern: Swift in the recommended way. However, I'll still use Vim as my editor. Apple won't take that away from me yet.

First, I will make the first screens - the "onboarding" flow for new users. I'm making this an app intended to be used on both Mac OS and iPadOS, and possibly iPhone, depending on how flexible its USB support becomes in the future.

Project initialization​

Some of this blog is a review of the developer experience. I'm coming into this with no Swift or Apple development background. This year, I switched to an iPhone, a Macbook Air, and an iPad Air. I like the ecosystem, and apps developed for a tightly integrated Apple-centric experience have been the best. You get what you pay for in that regard. So far, it's been fun - Xcode updated itself, and it tells me what's new. I initialize a new project; it makes sense so far. "Bundle Identifier" makes no sense to me, but it seems to be a namespace: organization.application. Then I see "Storage" has two options: "Swift Data" or "Core Data." I asked ChatGPT (4.0) which to use, and the answer is that Core Data is better for my needs. It's an object graph. I like graph databases. Selecting "Core Data" also opened up the "CloudKit" option, which sounds pretty rad. I'll give it a try. "Include Tests?" Yes, please.

It makes a template app. A panel on the right is loading, showing an error related to provisioning and certificates. I need to spend $100 a year on the Apple Developer program. Okay. I have to scan my ID, and now I have to wait...

That's it? That's all I can do today?

There's a bunch of rigamarole required before even getting started developing. I did expect that.

I'll write the next post when things move forward.

I've got lots of plans for what you will be able to do with Hamadapter. Let's list them:

1. Use Hamadapter to Control amateur radio transceivers and receivers, including base stations, mobile stations, handheld transceivers, SDRs, and remote receiving stations. Control multiple radios at the same time in a coordinated way.
2. Listen to and understand more communications with tools and analysis powered by machine learning: transcription, QSO assistance, denoising, signal classification, and wideband "skimming." Hamadapter will Demodulate and decode the most popular and some unpopular communication modes.
3. Log your contacts effortlessly, more quickly, and with more detail than ever. Logs can include automatic transcription, geographical and time-related information, information about the environment such as solar weather, and high-resolution power, loss, and reflection measurements. Analyze your logged data later to help you improve your station and achieve your goals.
4. Tune your setup and plan using valuable tools for analysis. These include solar weather, HF propagation analysis, antenna analysis and design, repeater registries, noise analysis and noise reduction, and reduction, as well as simple calculators that are commonly needed.
5. Connect with amateur radio communities such as QRZ.com, POTA, SOTA, LotW, and others. Update QSO logs and synchronize them between multiple providers.
6. Learn using interactive educational resources built into Hamadapter that guide you to helpful solutions and improvements without being overbearing—no boring videos or books to read.
7. Plan your contacts and activities with propagation prediction, DX window identification, net calendars, and satellite windows.
8. Do a lot of these things without a radio through online shared receivers. Share your receiver with friends.

Not all of this can be version 1, of course! That's why I intend to embark on this project carefully. The first thing I will be working on will be the "front-end" of the radio usage. To make that work, I want to make this application the greatest SWL (shortwave listening) application you have ever experienced. If you can't hear them, you can't work them. It's better in radio to have good ears and a weak mouth than a large mouth and no ears - sometimes called an "Alligator" by amateur operators.

This blog will contain a series of posts documenting the app's development. It will be pretty simple - I will be covering the broad design ideas of the app and how it works rather than getting into the nitty-gritty of the code itself. Remember, this app isn't open-source and does not have plans to be. These articles allow those interested in an app like this to follow its development.

The first posts will be a series on the overall architecture of the audio pipeline and culminate in the "panadapter display," which will be a central feature of the app. Be aware that what you'll see here is some initial iteration and experimentation - I expect the final product to be radically different. I also may keep some details private to maintain some delightful surprises for when the app launches.