Rob Fahrni

Brent Simmons

And it seems retro in the worst way that we’re still using anything other than a scripting language for most of our code. We should be using something simple and light that can configure toolbars, handle networking callbacks, query databases, manage views, and so on. And maybe with a DSL for SwiftUI-like declarative UI.

Almost none of that code needs to be in a lower-level language like Swift or Objective-C. It really doesn’t. (I say this as a performance junkie!)

It could be in Ruby, Lua, Python, or JavaScript. Better still would be a new language invented specifically for the problem of writing apps, something designed to make the common challenges of app writing easier.

We did have this stuff decades ago. Not for app making in general, sure — but now it’s 25 years later, and a company like Apple could make this real for all its app makers.

Where to start? Let’s start by saying I agree 100% with Brent. Having a built in scripting language with dynamic UI updating and easier ways to build code and UI would be absolutely incredible! And, like Brent says, I’d love to see Apple make this happen.

A hojillion years ago when I worked at Visio we had VBA (Visual Basic for Applications) integrated right into Visio. It was a fantastic way to build custom Add-Ons for Visio. You could embed your VBA solution right into your template or document so folks could invoke it right from the app. This allowed folks to make fancy automation to fit their particular need and do it in a high level scripting language that could control Visio in all kinds of ways! I loved it! I spent a lot of time working on Add-Ons to Visio in C and C++ but I used VBA to test things before implementing them as an Add-On — Add-Ons had the advantage of being usable app wide.

I’m not sure how VBA is used in Visio today but before I left Microsoft had added a way to build your solution code into binary form so it could be signed before including it as a part of your solution package. It was such a marvelous development environment.

Now, if you’ve ever used VBA in Visio, Excel, or Word you know exactly how powerful it is. Could you imagine having access to something like that within your Xcode dev environment that was fully integrated, or even supported like VBA in an application? Yes, it’s a lot of work to make something like VBA work but it is so worth it.

Brent mentions Ruby, Lua, Python, and JavaScript as the scripting languages but I have to say Microsoft’s Visual Basic for Applications is so much easier to understand and use than any of those languages and it was easy to open functionality to it using Microsoft COM, IDispatch specifically, in the app. I know, COM has a bad reputation for being difficult. Yes, like I said earlier, it’s a LOT of work, but it’s so worth it when you can open all that power to your users and yourself! Taking that to the next level, like Brent’s talking about, would be a huge boon to Apple Platform Developers. AppKit, UIKit, SwiftUI, Objective-C, and Swift are still too deep to move quickly. If developers creating code for any of Apple’s platforms ever took some time to use VBA they’d see what I’m talking about. The paradigm is a bit different than they’re used to but, hell, I was so confused when I came to iOS development! They’d get used it after a time.

Building UI and code behind VBA forms is so easy. Drag and drop a UI, double-click on the element you’d like to add code for, and write your code. That’s it. It’s that easy! I would totally embrace this idea for application development on Apple platforms.

You can build at a higher level today using awesome tools like Xojo that give you a very Visual Basic like experience complete with a drag-and-drop forms builder just like Visual Basic!

Psst, did you know that folks have been scripting applications for iOS, complete with dynamic UI updating, with React Native? Yeah, it’s true! I’ve been working on an application like that for the last two years. We’ve almost completely rewritten the application in 100% React Native, which uses JavaScript as its backing language and a way to build UI in a very HTML/CSS manner. Think SwiftUI with web technologies. It works.

I know of many applications using Electron to deliver cross platform apps, like 1Password. They used Rust for mission critical code and put an Electron “front end” on top of it. Microsoft has fully embraced React Native. They like it so much they’re the primary maintainer of React Native for Windows!

Am I saying React Native is a perfect solution? Hell no! It’s a terrible developer experience in my opinion. Most folks use Visual Studio Code — I prefer Nova myself — as their editor and don’t have a nice debugger to fall back on. Nothing is integrated. It’s a bunch of tools losely hung together by duct tape that let you kind of see what’s happening in your app. Hey, if you think console.log is the height of debugging then this environment is for you! 🤣

In the end I, like Brent, would love to see a modern scripting environment that’s embedable or standalone that is fully supported by and used by Apple internally to create applications. The embedded environment is very enticing to me. Something like Visual Basic for stand alone development and Visual Basic for Applications for embedded scripting would be absolutely incredible!

Modern means easy to use UI builder and code behind that is a super simple language like BASIC and on top of it make it easy for third-parites to make extensions to the environment and provide code modules that give developers the power they need for specialized applications.

Look at Xojo. That’s it. Apple, buy it and make a version that’s 100% built for your platforms and is embedable in applications.

I’ve been going to Grit, my favorite coffee shop, for the last six Sunday’s to work on Stream. It’s been really rewarding to spend the morning working on it. I typically work from around 8AM to noon, then grab Chipotle for my daughter and I and head back home.

That four hours of time has given me so much joy and recharges me for the week ahead. I cannot imagine how much better Stream could be if I were able to do this five days a week for five to eight hours a day! I might actually be able to make some real progress on the Mac version! 😱

Today I’ve managed to kick a beta build out the door. What I expect to release is version 1.6.0 as soon as Apple opens the door for glassified releases. Now, don’t expect much. Even with my four hours at a time to work on it I’m still very slow and the feature I’ve added isn’t glassy, at all. It’s something I’ve wanted to add for a very long time. It’s a feature meant to make things easier to subscribe to feeds. That’s all I’ll say about it for now.

What’s next?

Well, I had wanted to create an entire new view for adding and managing your subscriptions. I really need a nice way to populate the app your first time launching it and give you some great options when you pop open the Subscribe view controller. My plan is to create a nice set of hand picked feeds for users and, perhaps, add a set of recommended feeds using Apple’s built in LLM models. We’ll see at some point I hope! As long as I’m able to continue spending my Sunday mornings coding I think I’ll be able to achieve a lot on the app. I have a lot of features to add and bugs to fix! There are a lot of usability things I could do to improve the app and a few bugs I need to take care of.

Where’s the Mac version?

This is a tough one. And it’s only tough because I don’t know AppKit as well as I do UIKit. Yes, Stream is still 100% UIKit and the Mac parts I’ve done are all AppKit. I’m thinking I may do some new features in SwiftUI because I need the practice. I’ve never built anything with SwiftUI.

I’ve struggled to get layout on the Mac working the way I’d like. My table view cells look like crap and even with help from a dear friend — hi, Josh — I haven’t been able to get it right. It’s terribly frustrating and makes me want to jump out a window.🤣 Maybe SwiftUI will let me make those cells work on Mac?🤞🏼

I’ve been thinking about breaking Stream’s inner workings into a separate package.

It would include; networking, parsing(RSS, JSON Feed, Atom, and HTML), data models, database(?), and any utilities around those items. The database bit is a stretch and should really remain outside of the package. It wouldn’t force a storage mechanism on anyone.

I’d like to do this to keep me honest about my separation of concerns and I just like the modularity of it.

It would, of course, use Swift Package Manager to create the package.

The big question rolling around my brain is this: Do I open source it?

Why not you ask? Well, it’s simple. I’m afraid my code will be dragged through the mud and that would destroy me. I love and appreciate constructive feedback and would absolutely take PR’s.

To get where I’d love to have it means creating the SPM and using it internally for Stream for iOS and Stream for Mac. I’d also like to make sure I’m using all the new async/await strictness put in place with Swift 6.

If I can get that far I’d consider open sourcing it. Maybe. 🤣

The other question is, would anyone use it?

No, it doesn’t suck eggs. That’s a clickbait title. Tell all your friends to visit. 🤣

SnazzyQ on Threads

The simplest tasks on iPadOS are either incredibly difficult and time-consuming, or they’re so unintuitive that even a 25-year Apple veteran can’t figure them out. Frankly, neither reflects well on iPadOS.

I have a very simple explanation for this.

Dude, it ain’t a Mac.

I know, I know, that’s a dumbass answer and iPad fans don’t want to hear it. I don’t blame you.

I’d like to be able to do all the iPad stuff on my iPhone with a second display and have it work more like macOS. I want full Xcode and a Terminal and free form windowing.

I know, that’s all on my Mac, today.

I’ll just use my Mac. It’s an amazing device. Besides, if Apple treated all the platforms the same how would they increase sales every quarter like Wall Street expects?

Maybe that sounds cynical. I’m not trying to be. Apple is a for profit enterprise. We all know that. Their goal is to extract as much money out of you as they possibly can. One great way to do that is make multiple different form factors that excel at specific niches.

I haven’t had a new iPad in years. My wife gave me her 9.7” when she upgraded a couple years back and I never use it. But if I were to use it, it would be for consuming movies and reading.

And for the reading bit my iPad Mini, gen 1, was the best device I’ve ever used for that. It was crazy light.

I use my iPhone for a lot of stuff. Social junk and writing blog posts. I’m using it now and it’s great for that.

Look, if I could have an iPhone that could display multiple windows and have all the things I get with macOS and the power of my MacBook Pro, I’d use this for everything.

As it is, it doesn’t work like that, and I don’t expect it to, ever.

Keep on keeping on iPad people. You never know, maybe someday you’ll get what you’re after. ✌🏼

Federico Viticci • MacStories

MacPad: How I Created the Hybrid Mac-iPad Laptop and Tablet That Apple Won’t Make

I may call it a monster in the title but this is a fantastic idea for a device in my opinion. I love that it has both iPad and macOS operating systems and both chipsets. It is after all just an iPad bolted onto a MacBook Pro bottom.

I can see a little cottage industry springing from this. I envision a top cover that fits the laptop perfectly and includes an intelligent dock, or tray, for the iPad to slide into. That intelligent dock would also provide a way to plug directly into the back of the MacBook complete with a hinge so you could close it and it would look just like a laptop from another manufacturer.

The dock would also need a way to provide power and a USB-C connection so Sidecar wouldn’t require a network connection to operate. When docked the docking system would autodetect it and fire up a session into the Mac and display it. I’m not sure how that would work, but it would be amazing.

When detached you could close the lid and use it in clamshell mode, hooking up a full size display, keyboard, and mouse.

This is the perfect device. ❤️

NetNewsWire Blog: “Our mission is to make the best RSS reader that we like making. We value stability, high performance, clarity, and lots of figurative air and space rather than a mélange of features.”

I love how Brent and the NNW team hold true to what they believe – and what they want – a feed reader to be.

If you haven’t checked out NNW you really should, it’s a great product.

MacRumors: ‘because it “opens the door for ‘Pro’ applications to come to ‌iPad‌."’

I picked that bit of a sentence from the article because it’s complete B.S. If folks want to bring Pro apps to the iPad they have the means to do it today on their Mac. Having Xcode on an iPad won’t magically make that any better. The Mac is the perfect tool for building Professional Mac and iOS apps.

Xcode on iPad would be fine. I can’t personally see using an iPad as my primary development machine. Mainly because I like using a bigger display for development. My 15in MacBook Pro display is about as small as I’d like to use.

If I could set the iPad on a stand of some sort, hook it up to my full size keyboard, mouse, and 24in display? That is something that may work.

We’re getting closer to that day, we’re just not quite there.