"Apple has said that it’s not merging iOS and macOS, but that sneak peek of iOS apps coming to macOS opens up a lot of questions about just what the Mac might look like in five years. Jason’s optimistic, but Mac users may be in for the biggest changes to the platform since the introduction of Mac OS X nearly two decades ago."
It's an interesting discussion, and I really do hope we see things from iOS move to the Mac, touch and Pencil support in particular. And the idea that "folks don't want to use touch on the Mac" is pretty dumb when you realize Apple sells a hardware keyboard for the iPad which works exactly the same way as a touch Mac would.
There are a couple of things that I was surprised the discussion didn't cover though. And what follows below are my half baked thoughts on what those are.
OpenGL and OpenCL were deprecated this past year, but Apple can't really get rid of those frameworks anytime soon because of legacy apps that aren't going to be updated to use Metal. It's a tough spot to be in.
Apple has dropped legacy frameworks very easily in the past though. But how exactly did that happen?
CPU changes. Once when MacOS went from PPC to Intel, and then once when MacOS went from 32 bit to 64 bit. Each time that transition happened Apple was able to say "OK, this legacy stuff just isn't going to be there on the new architecture". And since you had to recompile apps anyway to make them run on the new architecture, developers kind of shrugged and said "Well, yea. That's what I would have done too". It made sense.
So are we about to see 128 bit Intel processors anytime soon, to facilitate this change? I doubt it.
OK then, what about a new architecture?
Oh. Hello 64 bit ARM.
OK, so now we've got a new processor architecture for the Mac and now we need apps recompiled for them. Nimble indie shops and apps like Acorn and Retrobatch would most be certainly there on day one (just like we were for PPC to Intel and 64 bit), but then you've got the giants like MS and Adobe who usually have to be dragged kicking and screaming into the future. What's Apple to do about them?
Well, what if they made it easier for other apps to possibly take their place or at least fill in the gaps until the giants can ship something? Where can we find a billion other developers that already have a codebase that's ready to be compiled on another architecture, because they don't have decades of legacy code to clean up?
And if you look at from this angle, UIKit for MacOS makes perfect sense. Even if it's only to potentially help with a transition, that may or not actually happen. It gives Apple leverage.
And since UIKit on the Mac has already existed for years (presently contained in the iOS simulator), it's probably not as big of an investment on Apple's part as you'd think it would be. For sure, AppKit engineers have performed heroics to make it work as well as it does- but it's not like UIView wasn't already compiling on 64 bit Intel processors. It's there today. It was there 10 years ago.
This could go completely off the rails too.
What if MacOS on ARM only ran these new UIKit apps?
That's a scary thought for this MacOS developer.
But then again, we already have this and it's called iOS on the iPad. And maybe, just maybe, and remember these are half baked thoughts, but maybe Apple is wondering if some Pro users might be better served by MacOS Touch 1.0 running on ARM.
Happy summer solstice everybody! (at least for folks in the northern hemisphere, and for folks in the south… sorry. It's going to start getting brighter for you though).
Today I've got a pair of minor app updates to annouce for you.
First up is Acorn 6.1.3, which fixes a number of bugs including one that stemmed from trying to use QuickLook on a file that was created with Acorn 1.0. For the one or two of you that this was affecting, hurray!
What's next for these apps? Work on Acorn 6.2 will begin shortly, as will Retrobatch 1.1. WWDC introduced some great new APIs that I want to take advantage of (cool new machine learning things), so that'll be a focus- as well as Dark Mode for Acorn and one other major thing I've got planned. Retrobatch will probably also get the Dark Mode treatment, but not until I've done it for Acorn first.
So it's going to be a busy summer, but I'm looking forward to it.
"As we’ve seen, this is far from a mere inversion of the default Appearance. Apple has gone through and fine-tuned the smallest details to make this work.
"For example, the window shadows are different between the Light and Dark Appearance. In Dark Mode, they are a little crisper and slightly more opaque, complete with an inner stroke around the edges of windows to help them appear more defined.
"Another example of this is Desktop Tinting, a technique Aqua uses to alter the grays used in Dark Mode to be more harmonious with the current Desktop picture."
When Dark Mode was first introduced in the keynote, up on the big screen, I was pretty disappointed. It looked incredibly garish. But after installing Mojave and trying it out in person, I've decided I really like it. I've got a bunch of work to bring Acorn and Retrobatch up to speed with it, but I think it'll be worth it.
All the newsletter emails have gone out, and the press releases, and the quick updates to the website and store, and I've even started on version 1.0.1 to fix a crasher. Which is all to say Retrobatch 1.0 was released yesterday!
We've been flooded with ideas and inquiries, which is always a good sign. And the sales aren't too bad either. Thanks to everyone who's tried it out, and the nice write-ups it's received, and if you haven't checked it out already- why not?!
There were times in the development of Retrobatch that I wasn't so sure it was a great idea to spend this much time on a new and unproven app. I usually start a little smaller. And it was supposed to ship last September. But the original beta testers were enthusiastic about it and finding interesting new things to do with it I hadn't considered. I was also finding areas of cross pollination between Retrobatch and Acorn (and which is only going to grow in the future).
For instance, the initial work to bring Metal to Acorn 6.1 was originally done in Retrobatch. Since I had no legacy code to worry about with Retrobatch 1.0, I started with Metal from the beginning. And with that experience I was able to figure out how I could move code around and refactor Acorn in an intelligent way to bring Metal rendering there. And of course a number of the nodes in Retrobatch are obviously derived from Acorn.
And all the experience with working with wide gamut images and deep colors in Acorn meant that I had Retrobatch able to flawlessly handle those types of images from the start.
It's nice having two apps that nicely dovetail each other, and can build on each other.
In the past when I would switch from working on VoodooPad to Acorn, it would sometimes take me a couple of weeks to get my brain in the right mode for dealing with the different problems. And while there's still a bit of a context switch when moving from Retrobatch to Acorn, it's not nearly the same as it was with VP. The architectures are very different between Retrobatch and Acorn, but they both use the same core libraries and that really helps.
So what's next? I've already started on Retrobatch 1.0.1, and I'm going to start working on Acorn 6.2 as well. But I've also already started on a number of new nodes for Retrobatch (like levels, compositing, writing animated gifs) so there will probably be a RB 1.1 release sooner rather than later.
And next week is WWDC, so I've got a little bit of celebrating to do there first.
Retrobatch is the name of my new MacOS app, and it's in public beta right now.
Retrobatch is a node based (not the JS language) batch image processor. A bit like Quartz Composer, and a bit like Audio Hijack. But for images. Lots and lots of images (or maybe a few or even one).
But to do it right, it would need to be a new app. And then sometime late last summer, I decided it was time and I started working on Retrobatch.
But why node based? Every batch image processor I've come across was linear. You put images in one end, and out they came the other side. But that's so limiting! What if it was possible to take a folder of images and then operate on them twice with the same workflow? What if you could create branches where one would resize images to 50%, and another write out PNG files with the @2x suffix added to the file name? What if you had a workflow that referenced multiple folders which combined into a single output?
And all the possibilities! What if you could read an image from the clipboard, apply a filter to it, and write it to a folder and to the clipboard? What if you had a way to separate out PNG images of a certain size from a folder and only do an operation to those? What if you could script the application in response to new images being added to a shared folder? What about if it could capture all the open windows of your favorite application as images, then apply a filter to those, and then write out a layered PSD of those windows? What if you wanted to apply a machine learning model against your images, to figure out which contains pictures of hotdogs in them, and then perform some action based on that?
There's like, a trillion possibilities. Probably more. Beta testers have been surprising me with interesting workflows.
Anyway, you can do all that with the Retrobatch beta today with a free trial.
When it finally hits 1.0, fingers crossed, there will be two versions of Retrobatch- Regular and Pro. Pro will have all the nodes you see today, including advanced features such as machine learning, changing bit depths and color profiles, processing with AppleScript and shell scripts, rules, and advanced metadata entry. The Regular version will allow you to do the basics like cropping, resizing, watermarks, and so on. And there will be two prices as well. But right now, while it's in beta, you can purchase Retrobatch Pro at a reduced price.
Charging for a beta app? Yep- Retrobatch is very useful in its current state and people have been wanting to give me money already. So who am I to argue? In addition to that, bundles are back at the Flying Meat webstore. If you purchase multiple copies of Retrobatch, or a copy of Retrobatch and Acorn, or any of the above, you'll get a nice discount.
"Since way back in the mid-2000s, we’ve been delighted to help folks create their own podcasts. It’s been over a decade since Audio Hijack first added the ability to record both halves of a Skype conversation. In that time, podcasting has flourished, and our product lineup has grown to include audio tools to handle nearly all aspects of a podcasting workflow."
I miss doing bundles, and customers loved them. Some even told me back in the day that they wanted to collect all my apps just because.
Any day now, I guess I'll be starting that up again.
Inpainting is the technique where missing portions of an image can be reconstructed / guessed at using the surrounding pixels. NVIDIA is now doing this in combination with machine learning. ML is turning up everywhere these days.
Here's an idea I've been tossing around lately- Apple should make an Instagram clone for iCloud users.
Instagram is one of the last social networks I use these days, which I actually enjoy visiting. But I always get a little twitchy using it because it's owned by Facebook (which I'm really not a fan of). And the ads are getting pretty annoying these days.
So wouldn't it be awesome if Apple made a privacy focused clone of it? I know Apple doesn't really do well when it comes to social services, but I'm wondering if a simple photo sharing site might not be impossible for them to do well. From the outside, it looks like it's just a scaling problem. You've got photos, comments, and a list of folks to watch. It can't be that hard.
Start small. Make it clean and minimal. Add a developer API. Grow it slowly with beta invites. Why not? It's a pretty good fit if you ask me.