How much should be in each app release?

Recorded March 24th 2020 – watch the full episode on YouTube.

As an indie developer, how do you judge what and how much should be in each update?

James Thomson: With Apple's iOS releases, they're working on them internally and they're turning a build every week and then they're trying to refine that process and get down to a point where they have something that they can ship and that will ship on time. Sometimes they have problems with that, as we all do, but it's like as I said with the supporting Apple's new features, the typical time you'll do that is a when iOS 13, 14, 15 roll out, so you have a deadline.

"I have an idea for something, something small, I can turn round and try it and implement it, see if it works and do that in a very rapid turnaround."

For those kinds of releases, for the supporting new Apple stuff, big releases, that's a line in the sand in September. Usually, and we're not sure quite what's going to happen this year, but the expectation will be sometime in June we'll probably get Apple releasing beta versions of stuff and new SDKs. Some of that might be rough, but you can get an idea of what's possible, or where they're going on things.

Paul Hudson: What's the direction of travel basically, what are they going to try and give us?

James Thomson: Yeah and then you're trying to match speed alongside them, if you see what I mean? So you go over the finish line at the same point that they do and that's often, especially last year, that was a very interesting process because there were a lot of things that I wanted to do, which I didn't get to because of problems with the SDKs, or functionality that Apple pulled at the last minute, or whatever and just running out of time and life getting in the way, which life always does.

So it's a very fluid process of trying to do these things. Somebody asked in the chat, because I say “we” – the “we” is myself and my wife, that is the entire company and my wife handles all the business-y sides of things, anything that involves money and the like and I just make all the dumb decisions and write the code and I do the tech support, but it is just the two of us.

I think, makes it a lot easier because if I have an idea for something, something small, I can turn round and try it and implement it, see if it works and do that in a very rapid turnaround. I'm not waiting on collaborators or having a discussion as to whether the idea is good or not because generally, I have such an ego that I'll think of course the idea is good.

Paul Hudson: Did PCalc start as a Mac app? Because today we know it's available on Mac OS, iOS, tvOS and watchOS, even tvOS." So it'd be great to know the evolution of that a little bit, but also at this point how much code you're sharing?

James Thomson: Okay, so there is an interesting lineage through the code. Going way back, when I was doing a competing science degree and this would be 1991. One of the courses that I was doing was user interface design. I have told this story in a number of places so apologies to anyone who's heard it, but one of our projects for the course was designing in HyperCard a central heating control panel. So just the kind of thing that you would see where you would have the temperature, you'd have some buttons to put the temperature up and down and maybe set it at a certain thing, turn it off and on, kind of thing that you'd see on the wall, or at least before the advent of smart thermostats and the like.

"It was a test project and it's always been a test project and it was the small thing that I wrote as the first app before I wrote the next app. I never really expected it to continue, or to take off. But then, it's been rewritten about four or five times."

For that, I designed a bunch of fake LCD graphics and buttons and things. So it looked like a real one, or as real as it could be on a one-bit 512 by 342 display. After that, we had started doing some Pascal programming and we were using originally Turbo Pascal and then THINK Pascal and all we were doing was kind of just basic, processing text files, levels of stuff. But I soon realized that the tools that we had had all the Mac libraries and APIs in them as well. I thought, "I'm getting pretty good at doing the low level code. I wonder if I could make an app?" So I bought the Inside Macintosh books at the time and sat down and just read through them in the summer and it was like, “let's see if I can do this." My test project was, I thought, “well, I'll build a calculator because I've got these graphics that I did, this fake seven segment LCD and these buttons and I'll reuse them and the easiest thing I can reuse them in is a calculator.”

Paul Hudson: So many folks will think, “Yeah, I'll just do a quick calculator.” And we do, and we stop there. You're here 20 years later with the world's most advanced calculator for Mac and iOS and similar.

James Thomson: It was a test project and it's always been a test project and it was the small thing that I wrote as the first app before I wrote the next app. I never really expected it to continue, or to take off. But then, it's been rewritten about four or five times.

So, let me get the order of this right, so I did the first version and it was written in Pascal. I then hand translated the core engine of that from Pascal into C. And I wrote C++ and Power Plant, which was the Metrowerks CodeWarrior user interface tool. Which was kind of a proto-Interface Builder-y type thing, where you do the interface on one tool. And then I rewrote it again using Apple's HI Toolbox, which came later on. And that was the point where I had a Mac OS X version. And I used it as my making a Carbon app that would run on Mac OS X and macOS 9 at the same time.

Sometime along that timeline, the dashboard widgets came along. And for dashboard widgets you could do a native code plugin. So what you could do is write the user interface in CSS and HTML, but have a backend thing that did all the actual hard work. So I took the code that I had and I stripped out pretty much all the user interface and Carbon specific bits. And I had this engine and I put that in the widget.

When the phone came around, and at this point I had not written any ARKit or anything like that, I was purely doing Carbon stuff.

Paul Hudson: All Carbon at the time. Wow, okay.

James Thomson: Yeah. So when the phone came around I thought, I need to learn how to do UIKit. And so I'm learning UIKit before I learned ARKit. And I thought, again like all of this sort of reaching and finding the useful thing in your back pocket, I had this library which was the dashboard widget engine which had no ties to the user interface from Carbon.

I can use that and I can quickly write a UIKit wrapper around that. And that was what the first version of PCalc was, or first version on iOS.

And then what happened was that grew over time and I added more and more functionality to it. Things like the layout, editing and a whole bunch of stuff. And so that engine grew and grew and grew. And I had this Mac version written in Carbon which was running quite behind in functionality. And I was kind of iOS first at this point.

So what I did then was I took the iOS app and I ported that to the Mac, way before Catalyst or anything like this. So if you're following along at home, the number of hops that this code has made. And a lot of the stuff, because I was doing a lot of custom UI, it was effectively a case of swapping the UIViews for NSViews, wiring up some of the things different, and the preference window and a lot of that stuff is different code.

“I’m experimenting with sharing as much code as possible, experimenting with multi window support, which isn't something that the current PCalc supports.”

But currently the case is, a lot like all the kind of, underneath the UI is all the same code. The UI code has diverged and that's why some functionality is in one and isn't in others. Like the layout editing, all the backend stuff is there. So the Mac version can support a custom layout that you save and export from the iOS version, and load into the Mac version. But I haven't rewritten the editing code on the Mac.

This brings us to Catalyst and technologies like that. If I can write the whole thing or at least as much as I can in one place and have it running on the other place, that would be ideal. Now the Dice app has become my test app, this is where I'm experimenting with things. So I'm experimenting with Catalyst. I'm experimenting with sharing as much code as possible, experimenting with multi-window support, which isn't something that the current PCalc supports. It used to support it on the Mac and it now doesn't because the code that came from iOS effectively has at its core a dashboard widget.

And the analogy that I've used a number of times, if anyone has seen the film Star Trek: The Motion Picture, I'm going to spoil the ending of Star Trek: The Motion Picture here.

Paul Hudson: It's about 40 years old now, right, so I think possibly safe on that one.

James Thomson: In that, the Voyager probe that was sent out from earth, has all these layers and layers of stuff built around it. And has become this sort of sentient being roaming the galaxy. And that is exactly what the PCalc code is right now.

Paul Hudson: You mentioned about iOS and macOS and Catalyst. How do you feel about the new cursor support for iOS coming?

James Thomson: Yeah, the hover stuff. So when I was doing the Catalyst thing, one of the things that came up was it would be really nice to have a popup button control that could display a menu.

"On the Catalyst side, they have the UIHoverGestureRecognizer, so you can move a mouse over something and see the mouse moving from the code. It works a lot like all the other gesture recognizers. I wired that up for the Catalyst side. And now they've basically unlocked exactly the same functionality on the iOS side."

And I wrote it for the Catalyst app. But it actually proved to be quite useful. And I tried to make it so that it would work well with touch. And it would work well with a mouse. It doesn't work perfectly in both sides, but it works enough that it was better than what I had.

On the Catalyst side, they have the UIHoverGestureRecognizer, so you can move a mouse over something and see the mouse moving from the code. It works a lot like all the other gesture recognizers. I wired that up for the Catalyst side. And now they've basically unlocked exactly the same functionality on the iOS side.

So I literally just needed to go in and change a bit and all that code worked perfectly. So I got all that code that I did, because I did it for Catalyst it was for free. And any improvements that I may make on one side apply to the other side.

“If you think of it like the functionality and the cosmetic side separately, you can get all the functionality of mousing over and clicking on things and doing stuff. You can get that working right now nicely. And then you can pretty it up when we get the final APIs.”

The other stuff that they are going to add, which we haven't officially seen any of the APIs for, are really visual things, it's like the little effect when you move the cursor over. And all that is really cosmetic. And that doesn't, as far as we know so far, they're not planning on wiring that up on the Mac side on Catalyst. At least there's been no sign of it so far. But who knows.

And so today you can do all of this stuff. If you think of it like the functionality and the cosmetic side separately, you can get all the functionality of mousing over and clicking on things and doing stuff. You can get that working right now nicely. And then you can pretty it up when we get the final APIs.

The Dice app that is currently sitting in app review, that, I just re-exposed all these things that I was using in the Catalyst app. And it works really well. And once we get the final SDK, I will stick another build in the queue once I've had a chance to officially play with those APIs. I have played with them, because the usual suspects have been messing around with them and seeing what they're doing.

Paul Hudson: Steve Troughton-Smith, also I saw Peter Steinberger doing a great job of figuring it out behind the scenes. Just digging until it worked basically.

James Thomson: So, that's another example of people in the community helping each other. It was a case of like, I was like, “so how does this API work?” And somebody will say, “Oh, try this.”

Then it was a case of just sort of messing around. You can do the basic stuff really simply. It's just if you've ever used the drag and drop interactions, which you can add to views, then it's the same kind of thing. You just create these pointer interaction things. And you can set some properties on them. That's probably enough to make it look quite nice. Then there's more stuff you can do to control cursor shapes and things like that.

Sponsor Hacking with Swift and reach the world's largest Swift community!