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 managed to kick nine builds of Stream out to beta testers. That’s the most I’ve ever done! I owe this all to the four hours of time I’ve reserved on Sunday morning for working on Stream. It’s been seven weeks of work. Like I said in my last Stream Work Note I’m overjoyed at having this time to focus work on Stream and, of course, have a really great Mocha while I do it. 😄

During my testing I noticed that the one new feature I’ve been adding to the app would fail when Stream was tiled with another app. That really stunk because otherwise it looked great to me! Today I managed to fix that outstanding critter and it feels really great!

I’ve had two other bug reports come in specifically for my iPad support — thanks Lucian and Sean!

The first bug was occuring when you’d pick a feed to subscribe to. That porting of the code has been synchronous since day one. I figured why do it asynchronously when the UI was going to be blocked while I added the feed to your list and parsed it. Well, newer versions of iPadOS didn’t like that and the app would crash hard. Yikes! Can’t have that. I fixed that bug earlier in the week or maybe last week, I don’t remember, but it’s out of the way and now asynchronously updates the app, be it iOS or iPadOS.

The second bug was a bit more difficult to fix only because I couldn’t reproduce it. It turns out it was happening consistently on iPadOS 16.8.2. So, I added that simulator setup and kerpow! 💣 It happened right away. YAY! 🥳 It turns out I’ve been stacking two navigation controllers on top of each other since I added iPad support a few years back. DOH! The OS was just tolerating it so I didn’t know. Well, it looks like Apple decided it wouldn’t allow that any longer, and rightfully so! I fixed that issue yesterday.

This morning was spent fixing the tiling bug and it’s now done and a new TestFlight build it up. If everything goes well with that build it could be my final build before Tuesday’s Apple Awe Dropping event. 🤞🏼

Have I ever mentioned I’d love to work on Stream full time? I didn’t think so. 😄

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?🤞🏼

Sean Heber via Mastodon

ChatGPT and other AI services are basically killing @Iconfactory and I’m not exaggerating or being hyperbolical.

Reading this sent chills down my spine.

Iconfactory has a very long history of creating beloved applications and designs for Mac and iOS.

Their designers craft beautiful interfaces, icons, and other illustrations.

To think they could go away because people are using AI generated slop designs and icons is gut wrenching.

I’m a huge fan of Iconfactory work. I use their apps everyday. Two in particular; Tot and Tapestry.

I’m writing this blog post using Tot. It’s perfect for it. Simple text editor with Markdown support and automatic save that syncs with iCloud. It’s an example of simplicity that is absolutely useful. I’ve been using Tot for years to write all of my blog posts, including Saturday Morning Coffee. ☕️

Tapestry is a new app. It is a new take on feed readers. Sure, it’s a competitor to Stream but it’s beautifully designed and implemented.

I’m a Wallaroo and xScope user and I’ve heard wonderful things about Linea Sketch.

Their craft is second to none.

Stream had the honor of being featured in the App Store in October of 2023. I worked with Iconfactory to create the banner Apple needed for the feature. It was a completely painless process and the results were beautiful and better than I could’ve imagined.

If you need someone to design your app, icon, or other materials, give Iconfactory a shout you will not regret it. ❤️

I messed with my Lock Screen and Home Screen a bit today. I updated McClockface to use the Get Schwifty style. I like it.

The Lock Screen is super simple. Black with the simple text “hello, human”.

Something we’ve become very good at, at WillowTree, is migrating native code to React Native incrementally. I’ve been working on a project for the last year-and-a-half to migrate a pretty big application to React Native and we’re not there yet. We’ve finally hit critical mass in the React Native codebase to begin the transition to a full React Native based application.

To start the migration we built bridges to the native iOS and Android applications to handle things like; networking, navigation, analytics, telemetry, and events.

Since the native applications had great code written for all of those things we were able to leverage it to build a brand new user interface using React Native. At one point we had a Platform Team who built out the Bridges between React Native and Native. Those teams consisted of two native iOS and Android developers and a React Native team of two. The two React Native developers built up the TypeScript side of things for communication between React Native and Native, leveraging our native bridges.

To make writing new React Native UI easier we had individual teams working on specific parts of the UI by feature. A mono-repo was created so the team could use Expo to quickly iterate the parts of their feature. The React Native Platform team made sure the App Team could mock everything and use the bridges as they’d be used with the native application. It worked out really well.

Since each feature area had its own team we would take their code and make a package out of it. Those NPM packages were then referenced and used in the native iOS and Android applications.

Let’s say we had a Social feature. That feature team would do everything to make that feature work as expected, complete with UI, business logic, and any navigation necessary to complete the feature. That feature would be bundled up into a package and deployed to a private NPM repository.

The native application would reference that package in its packages.json file by its version number and it would be installed using NPM. Once we had it packaged into the native application we would reference it using the supplied Meta React Native library code in each native application. Once the React Native Framework was strapped up it was easy to wrap up each React Native feature and display its UI, where it was completely controlled by the React Native developers.

Networking and Models

To supply the React Native code with models ready for consumption we bridged to the native applications since each had already implemented network and data caching code. The React Native bridge allowed the caller to supply all the arguments necessary to make a network request and the bridge code bundled it up, sent the request, received data (or POSTed it), updated any local caches, and forwarded it to the React Native code where it would become a TypeScript model object ready for them to consume. It was some of the first code we created and really opened the door to productivity right away.

Navigation

I’m going to talk about this from an iOS perspective, since it’s what I know.

This was a bit tricky. Navigation from React Native to Native isn’t a straight line. When creating a React Native feature we first constructed an RCTRootView. This would ask the React Native framework to load a particular feature and host it inside the RCTRootView. Once the React Native code was loaded it was running in its own little sandbox, so to speak. It didn’t have any knowledge of the outside world, except through our native bridging code.

Our navigation bridge was quite simple. It was a single method that allowed code to navigate to a native UI View Controller or to a React Native View Controller based on the name of the UI the developer wanted to navigate to. Yes, the bridging code had to know about every view controller in the application, to an extent. The developers of the iOS and Android code thought ahead and created a really nice set of routing classes. Those were leveraged to display most view controllers, native or react native.

While each feature was self contained this navigation bridge was there to provide the glue that allowed us to display anything we wanted.

One bit that felt weird was the need for the React Native code to know when it had to close itself. The native code built the UI and was hands off at that point but we had to know when to tear down that UI. The React Native code would tell us when it had to go away. Unbalanced, but a compromise that worked beautifully.

Other Stuff

There are a few more bridges we built. Each defined in a separate package supplied by our private NPM repository and built into the native applications. I’m not going to get into those now. This post was kind of off the cuff and I could go really deep into the architecture, but that is for another day, if at all. 😄

I will say this. If you were not aware you were looking at a hybrid React Native / Native application you wouldn’t know. Since React Native uses native controls for each platform you are truly getting a native application. Sure it’s using the JavaScript engine from the platform for writing code and sure the UI is described in web technologies, but the Meta React Native framework does all the work to display 100% native UI controls. That’s what makes it difficult to tell the difference.

Apple Newsroom

Apple honors 2024 App Store Award winners

Congratulations to all the winners!

Not gonna lie, I’d love to have one of those blue beauties on my shelf. 😍

My apps need to be so much more polished and feature rich before I could even dream of such an honor. I have the likes of Unread, Reeder, and NetNewsWire to compete with. All beautifully designed and developed.

Having said that, you should go download Stream and leave me a tip! 😃

Gotta say it, the Dutch Brothers Coffee app is really well done. It’s beautiful, stable, has a personality, and does exactly what it’s supposed to do. Lets you order and pay for coffee.

I wonder who makes it? Do they do all dev work in house or do they have a studio, like WillowTree, work on it? I’m super curious.

If you know, send a message my way, rob.fahrni@gmail.com.

There is this weird part of me that wants to go back to writing cross platform C++. All of my cross platform work was for Windows and Linux. The itch has been there since I moved to iOS code — and I spent [two years in between iOS dev jobs working on a cross platform SDK for Pelco’s video encoding, decoding, and recording devices, all in C++. It never made it to Linux but I spent a whole lotta time working on Pelco’s X SDK. That was our version of a cross platform SDK we used internally to build a cool pipeline framework called MPF, or Media Processing Framework.

Why the draw. I’m not sure, but I think it’s probably because it’s the language I know best and I did a lot of work with the Windows API, which was also a strong suit.

I still haven’t, and don’t think I ever will, embrace the Mac like I did Windows. At the time I was a Windows dev the platform was simple, before COM and OLE 2.0. The Windows API was so straightforward.

None of that is true any longer. Not for Windows or C++. I bet I wouldn’t even recognize modern C++. C++ 11 changed A LOT in the language and it’s only advanced since. As for the Windows API, folks still use it but you should be doing something different, like using WinUI 3.

The thing is, I REALLY want to complete Stream for Mac and my new super top secret project: Rooster. Yeah, it’s not so top secret, and I finally gave it a code name, but if you know me you can probably suss out what it would be given my love of blogging.

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?

Had to mess with the home screen again. The new widgets in McClockface are incredible! I love this new Casette Tape widget is beautiful! 😍

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. ❤️

Craig Hockenberry • Iconfactory

This post will explain the technology behind Project Tapestry and how we tested it as a prototype. We’ll keep this discussion at a fairly basic level: if you’re a web or app developer, you’ll have no problems following along.

And if you think I’m going to describe RSS feeds now, think again! We’ve come up with something completely new.

I’m excitedly looking forward to seeing the final product and I hope they make their stretch goal of bringing it to the Mac. 🤞🏼 Please, go read about Project Tapestry, and if you’re so inclined please support their effort. I backed them early, it was a no brainer for me.

I really wanted to talk about the choice the Iconfactory made to create a highly extensible platform for plugins. It’s a darned great idea! And I love their choice of pushing network requests through Project Tapestry itself as a way to guarantee plugins can’t phish out user data or credentials to exploit later. 👍🏼

As I was reading the post I came across Craig’s mention of the app having a sendRequest method used by the JavaScript code to make network requests. This grabbed my attention and made me realize this is a way better version of a React Native application.

What I mean by that is, React Native is hosted inside a native iOS application framework and uses native iOS controls on its view controllers or its version of a view controller. The JavaScript code drives everything from networking to user interface (it uses UIKit internally) to render content for the user to interact with. This allows developers to write their app using straight web technologies and run it on iOS and Android.

The project I’m currently involved in is an existing eight year old iOS application built with a mix of UIKit and SwiftUI. On the flip side the Android app of the same age is built using Java and Kotlin with a mix of the original XML based UI and modern Jetpack Compose. They’ve both taken very similar and not unexpected paths.

Enter React Native

Something our client wanted to do is integrate React Native into the existing applications. This has been done before by Airbnb and more recently by Shopify. Each with very different outcomes.

So all of that to say, ours has been successful, in my opinion. We’ve been able to fully integrate React Native and carve out a little set of API’s in the native application we expose to the React Native developers to do work the native application is already doing for them for free. Part of which is all the networking calls.

In the Tapestry blog post Craig points out sendRequest. It’s the call they use to handle requests to the internet for the JavaScript plugin. In our application we’ve exposed a makeRequest call that handles doing any type of network request; GET, POST, PUT, PATCH, or DELETE, and returns a Promise to the caller. Hey, sounds like the Tapestry code! 😄

I have it on my todo list to learn JavaScript. It’s been there for years and years because I knew I’d need it at some point. I really need it now. I can’t see React Native projects going away for the WillowTree team. They’re a very popular way for our clients to get cross platform code and get an iOS and Android app out the door simultaneously without having to spend time, money, and effort on two completely separate code bases.

Over the course of our integration work I’ve done a smidge of TypeScript code to allow other TypeScript devs on the team to make calls into the APIs we’ve exposed in the native application.

It’s been fun and I see a place for JavaScript/TypeScript in my native development world.

Project Tapestry is BETTER!

As for what Iconfactory is doing, I think it’s a much better version of what React Native does. It gives them the best of both worlds. A beautiful, hand crafted, fully native UI, that gives JavaScript developers the ability to extend the app. That’s a lovely thing. ❤️

I’ve been a Castro Podcast player user since they introduced 1.0, I couldn’t find when 1.0 shipped but it must have been over 10 years ago.

Anywho, it’s a great app and the best podcast player for my tastes. The Inbox where all podcast episodes are collected is perfect. It allows you to choose what you want to listen to and organize the list however you’d like. That’s really nice! The Inbox is noisy but the Queue, where you play them, is nice and organized. Plus the UI is simply gorgeous and well organized. In my opinion it’s the best podcast player in the market.

So, why all that intro to Castro who-haw? Well, once again, Castro has gone off the air. This is the second time in the last few months we’ve lost the backend service and the second time in the last few months Castro’s parent company — Tiny — didn’t say a thing about it.

Not only that but the Castro website has gone dark. If you try to browse to it, as of this writing, you’ll get a website not found error.

The app is still available in the App Store but it’s useless without the backend to support it.

What the heck is going on at Castro, and more importantly, Tiny to allow this to happen without informing their user base what’s going on?

Did they sell it and the new owners dropped the ball? Did they just give up on it and let it waste away to nothing through neglect? As a longtime user I’d love to know what’s going on.

Since it’s still available in the App Store is Tiny collecting subscription dollars? That’s gonna be a real mess to untangle if folks downloaded and subscribed for the year.

So many questions. Once again I wish I were a wealthy fellow so I could buy it and update it so it doesn’t need its own backend to function.

I’m on a project at work using React Native but not in the typical way, which is to say it didn’t start as a React Native project. It’s an exiting app out in the world actively uses by, I’d imagine, tens and tens of thousands of people. Perhaps hundreds of thousands. Bottom line is, it’s a frontline app and is important to our client.

Our client has a large team of React developers and a team dedicated to the design and development of reusable React components for the company. They’ve done an amazing job creating a platform for their devs to build on and would like to have those devs build mobile experiences as well. I can’t blame them. They’re very good at it.

They currently have native iOS and Android apps that are almost ten years old and use various frameworks and technologies. Your typical legacy codebase. That’s nothing new or frightening. All code develops its rough patches over time and as time goes by we go in and turn the soil so to speak. We replace outdated frameworks developed out of necessity with new platform supplied frameworks and our code is more robust and easier to read and maintain, especially for developers coming right out of school.

With all that in mind here’s what our client is looking to do. We are building new features in React Native and leveraging much of the internal native code to fetch network data, build models, and return that data to React Native code. The API or Interface to the native code is well defined and implemented on iOS and Android. The React Native team code is the same for both platforms. I’m part of the platform team integrating React Native into the existing app and providing the API/Interfaces to the React Native developers.

Like I said, this is a non-standard way of doing this but it’s been done by others with stories of success and failure. I believe we are on track to have a story of success. It’s not going to be free of bumps along the way but we’re making really great progress and I believe we will hit a steady working state as soon as next week. That means the foundation to strap up and host React Native code is in place and working as expected. Now it’s time to build out the API more thoroughly, driven by our React Native developers need for specific data or business logic. It’s a single app, purpose built, API. The idea is to hide any ugly code on the native side and keep the API to the app clean for the React Native developers.

Cool Bits

One of the extremely cool things about how we’re approaching it is how our React Native devs work.

They work inside of a separate application while they’re developing new views and logic. It allows them to move more quickly and not have to rely on the native apps to update before writing their code. It also means they don’t have to worry about keeping the existing native app building on their computers. That can be a headache, I wish it weren’t, but it can be. More on that in a bit.

How does it work? Well, when you create a brand new React Native project you run some tool to generate the project for you. It creates the scaffolding for your React Native code as well and iOS and Android host app projects complete with the frameworks necessary to build the native host apps. On iOS uses CocoaPods. I don’t know what Android used.

That allows the React Native Developers to run ahead of the platform native developers to build their UI’s.

Ok, so how does that work?

We negotiate with the React Native development team to define an API signature for the native apps. They build a mock version of that in their development host app that matches the agreed upon signature and go about coding.

We build out the platform side to do the true implementation. When we have something to test we pull over a packaged version of the React Native code and give it a spin. If there are problems we work directly with the React Native developers to figure it out. Once it’s ironed out it’s wash, rinse, repeat. We currently have a feature built by WillowTree and one built by our client working in the development host and in the existing native applications.

It’s pretty darned magical when it works! 🧙🏼‍♂️

The Ugly Bits

Getting the React Native frameworks and nuanced build settings and scripts in place has been a bit of a struggle but I think we may finally have all that figured out. But it is painful for a native developer who’s used to opening Xcode, loading the project, hitting build, and it runs. Sure, we may have to use CocoaPods to get started, but that’s rare now since Apple introduced Swift Package Manager, or SPM.

SPM is integrated into Xcode and works really well. I’ve never had an issue with it, knock wood, and went through Stream a couple years back and replaced my use of Carthage and CocoaPods with SPM. It’s been glorious.

This option is, unfortunately, not available to React Native projects AFAIK. That’s fine. CocoaPods works and is familiar.

The one really ugly bit, at least to me, is the requirement to use npm. I know web devs are accustomed to using it but it feels really strange and fragile to use these two package managers to be able to build and run an app that includes React Native. I know I’ve run into random issues I can’t explain when node packages change or are added but that’s just me being a big whiny cry baby developer. I understand it well enough to be dangerous but I don’t currently have that deep knowledge I like to have. I’m learning new stuff everyday but I’ve only scratched the surface.

Great! How do you feel about it overall? 🤔

I can see why companies are making this choice, especially companies with an army of React developers. It makes complete sense for them to build great UI with their existing developers. And, yes, you can build a great iOS UI with React Native. I’ve witnessed it first hand. If you didn’t know a view was React Native you wouldn’t know the difference in this app. It’s seamless. It’s great in that way.

Angelo Stavrow

but oof — it still feels like I’m working with a business decision, rather than a sharp tool.

I think Angelo’s quote above is a nice TL;DR for me. On the downside I really dislike the tooling. It feels so arcane. I’d love to see something integrated into the Xcode UI for package management and project settings. That’s probably asking a bit much but I’d rather have some do an amazing job of all this scaffolding so I can just hit the build button to run the app.

All that said, it’s still worth using. 👍🏼

RIP Apollo🪦😔

What would be a good name for a blog editing tool? Just for writing, editing, and publishing. Native iOS and Mac. A companion to Stream, as it were.

Would a combined blogging and feed reader app be appealing?

Before doing Stream I was originally doing a blogging tool. I did Stream because a feed reader was easier than doing a blog editor. 🤣

It’s unfortunate I waste so much time thinking about these things but I want them for myself. I figure others might want them too.

I didn’t do much on day two. I did a very basic layout that displays the long URL copied to the Pasteboard and got the link off of the Pasteboard and placed it in a text field. The layout it nowhere near final.

Then I decided to get Chipotle for lunch and got really lazy afterward and didn’t do any additional work.

Even though I was pulled into work yesterday I managed to start the rebuild of Arrgly to use SwiftUI. I do NOT recommend doing this on a real software project because rewriting an app is a sure way to lose money and possibly destroy your business. I use Arrgly as a learning application because it’s tiny and fairly easy to rework.

Yesterday I spent the day reorganizing the Xcode project. It was organized into different folders to make it easier to find things. I had it organized in groups like; Network, ViewModels, Utility, Parsing, etc. All of those lived under the main Arrgly build target and I’d like to reuse all of that code for the SwiftUI build.

Step 1

I added a new build target for the SwiftUI project, called SquishU for Squish Universal. Oh, yes, I’m renaming the app to Squish because I really hate Arrgly and that’s the best I could come up with.

Step 2

Once I had the new target I created a group called Shared and moved all of the code that could be shared between the two targets under the Shared groug and made sure the application could still build and run.

So far, so good.

Next

Now I need to sit down and start reworking the UI using nothing but SwiftUI. This is where the rubber meets the road and who knows how long it’ll take me to actully complete the work.

With any luck this will be in the App Store soon. The last version of Arrgly was pulled from the store by Apple because I didn’t rebuild it with a newer version of the iOS Frameworks. It still works fine on my phone, you just can’t download it any longer.

Good morning! It’s Christmas Eve – for those who celebrate!

Look, I’m a native California boy. It’s mostly sunshine and warm weather year round. Sure we’d get down in the high 20s overnight on rare occasion, but nothing like we’ve experienced in Virginia this week. It’s been pretty darned frigid. The temperature at the moment is a balmy 8 degrees outside, with a feels like of -7. That’s just wild!

Anywho, first cup of coffee is in the mug. Time to compose the post. ☕️

Mike Hurley

Many people using PCalc on their shiny devices today don’t realise that the app has been around for a lot longer than they think. In some cases, a lot longer than they’ve been thinking.

Happy Birthday PCalc! 🎂

It’s impressive to have an active 30 year run with a piece of software. Congratulations on 30 years and counting James Thomson!

Craig Hockenberry

By now, you probably know where this is going: yes, I wrote my own utility and call it SimBuddy. It’s a FREE download from the Iconfactory.

Craig Hockenberry is a long time Mac and iOS Developer. He’s best known as the creator of the first Twitter client, Twitterrific, but he’s also developed many fun and useful apps for the Iconfactory.

If Apple gave out lifetime achievement awards, Craig would be deserving of one.

Thanks for another great development tool, Craig!

Joel Spolsky

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

This is an oldie-but-goodie. The Joel on Software piece above is from 2000 and touches on something that can destroy a company quicker than anything: rewriting software.

The article was brought up somewhere this week because Musk is reportedly looking to rewrite Twitter.

I mean, dang, dude! Maybe try to understand how all the things work together before jumping to that conclusion. A lot of cool stuff was happening before you blew the place up.

Randomly thinking back to my time at Apple.

In 2013 when the iOS side of iTunes U, Podcasts, App Store, and Remote were owned by a team of 7 engineers. Each app source in a different source control.
I was lead for iTunes U. I was told a few things by my new manager
1) Don't ...

— @taquitos@macaw.social the new Taquitos (@taquitos) December 5, 2022

I’ve been trying to stay away from linking to Twitter but I couldn’t resist this tweet because it captures something a lot of modern devs should hear.

Basically the tweet thread goes on to explain how broken Apple’s development process was broken on a particular team.

I’m not saying alternate forms of development are necessarily bad but grinding devs into the ground is not good, at all. People need time to live, and sleep.

Futurism

It’s not just Tesla investors who are at their wit’s end with CEO Elon Musk, who has been making a huge mess of his Twitter takeover.

Ah, yes, The Musk Effect. He’s dragging Tesla down with Twitter and I’m shocked the Tesla Board hasn’t fired him.

Tech Dirt

But, really, after all this, I cannot fathom how anyone can possibly get all that excited about joining yet another centralized social media site. Perhaps I’m biased (note: I am biased) because it was my frustration with the problems of these big, centralized social media services that made me write my Protocols, Not Platforms paper a few years ago. But, after all of that, the big question that kept coming up about it was “sure, but how would you get anyone to actually use it.”

Here’s to the Open Web making a comeback! We now have Mastodon and Micro.blog to fill our Twitter mojo and both run on open standards like ActivityPub and RSS.

Dare Obasanjo

A friend asked what I think will happen to Twitter. Here’s my assessment

Nice little Mastodon thread from Dare sharing his thoughts on the Twitter mess.

Denise Yu

You’d like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone’s going roughly in the same direction.

This piece from Denice is required reading for any Software Developer. It explores the position know as Staff Engineer or Principle Engineer in many companies today.

At WillowTree was have a dual track for Software Developers after the Senior level; Staff Engineer or Associate Engineering Director.

I personally reached a point where I decided it was time to change direction and focus on building teams instead of coding, so I became an Associate Engineering Director.

It is interesting to note the Staff and Director positions overlap in significant ways but also have very unique traits. The Director position is a people management and team building position, the Staff position does deep dives into technology and can master just about anything.

Anywho, go read Denise’s piece, it’s very good.

Alexandre Colucci

Like in the past years, I will try to answer a couple of questions: How many binaries are in iOS 16? Which programming languages are used to develop these apps? How many apps are written with Swift? What is the percentage of apps using SwiftUI versus UIKit?

I had to share this because I too find it interesting to know how much Apple is eating their own dog food when it comes to their developer technologies.

Swift seems to be making real inroads and SwiftUI (worst name ever) is starting to show itself.

I’ve been thinking about doing Stream for Mac with SwiftUI. It is the future of development on the Mac and iOS. All devs need to learn it at some point.

Dan Sinker

Newsrooms should not spin up instances for their reporters partially because this is too new to dedicate strapped staff to

I’ve been pushing the idea of news companies spinning up their own Mastodon servers. Dan does make a good point about not doing that. If Mastodon could be enhanced to export all posts to another instance I have a feeling Dan wouldn’t be as opposed to the idea. As it stands you can move instances but it only keeps your followers, you lose your posts. That’s no bueno.

Adam Davidson

We want the field of journalism to take ownership of the ways stories are distributed and audiences are engaged.

With the most recent flight of users from Twitter Mr. Davidson spun up an instance of Mastodon for journalists. That was a brilliant idea and provides a bit of distance from the journalist to their organization. It’s a great alternative to news orgs spinning up their own.

The Atlantic

There has never been any mystery about what happened on January 6, 2021. As Senator Mitch McConnell said at Trump’s second impeachment trial, “There’s no question—none—that President Trump is practically and morally responsible for provoking the events of the day.”

In many ways I’ve lost confidence in our Justice system because it treats the rich, politicians, and white people differently than everyone else. Combine more than one of those traits and you’re likely to walk away unscathed where someone who works at the coffee shop, is poor, and dark skinned is totally screwed.

It’s not right. TFG must be brought to Justice. Our system requires it if our democracy is to survive.

Ghost Only

How to have a good internet experience in 8 easy steps

I usually avoid posts that include “steps” or “X reasons” because they’re usually really bad click bait type articles. This one isn’t. Go check it out.

Mark Jardine

When I heard the news that the sale of Twitter went through, I was literally shaking. My family and I have had a rough year health-wise. My wife was diagnosed with Lupus and my 5 year old started having panic attacks out of nowhere that resulted in seizure-like symptoms. We had to up our health insurance premium to $2500 a month (Yay America!) for access to specialists previously not in our network. Then I had a bad crash on my bike where I had a concussion and lost consciousness.

Read the entire thread it’s a really great read by a Tapbots co-founder. They’ve gone all in on creating a brand spanking new app for Mastodon called Ivory and it’s stunning. I’d expect nothing less from this little company of two.

Beyond the iOS version I hear they’re bringing their Mac version to Mastodon as well. Sweet!

Now, if we could convince The Iconfactory to bring good ole Ollie to Mastodon I’d be happier than a pig in slop.

I have plenty of work to do on Stream, plenty. I have a list of features a mile long. Some submitted by the fine folks using Stream — thank you! — some right out of my goofy brain. Yes, I wish I could move faster, yes I’d like to do this full time. Yes, yes, yes!

The best I can do is muster is an hour here an hour there. Anywho, I’m putting this idea out here. It’s one I’ve added to the Stream list. It’s absolutely something I want.

Read Later

I use Pocket as my read later app. It plays a crucial role in collecting posts and news for Saturday Morning Coffee. What I’d really love to have is a read later feature in Stream. One of these decades it’ll happen.

Twitter Support

It would be much better if these features were part of Twitter.

First, I’d love to be able to follow Twitter Lists as if it were an RSS feed. This is a very selfish feature because I have a Twitter List called Politics. It has all my favorite news sources and other sources of politics. I made it because Politics can really stress me out, especially around election time. I’d like this so I could follow any list from any Tweeter, including my own. Of course it would be best to be able to do it without going through Twitter’s authentication system, but I supposed I need that so I can use the API.

Second, it love to have an extension to Stream that could unroll a Twitter thread into a nice single post. That’s it. That’s the feature.

Here’s what it would look like. This example used Thread Reader and Pocket. Stream could be great at this if its darned developer would get off his butt and write some code. 🙃

I managed to work on Stream a bit over the weekend and once again I have that ”I wish I could do this full time” desire.

I have a list of things to do a mile long. I checked my checkins — say that five times fast — and I haven’t worked on the Mac version in well over a year. Pathetic.

I did manage to get very close to finishing off a new little feature over the weekend. This feature will allow you to set the number of days Stream will keep posts. It’s a sliding scale from one to 31 that defaults to 30, because 30 is the hard coded value in the version in the wild.

I like the way it’s come together and need to fix an annoying bug that cropped up on iOS 15.5 — possibly other versions — then I’ll get a beta out the door.

For the technically minded. This bug is clearly my fault. I have a layout issue my table view cells, there are two types. It would seem that iOS 15.5 has tightened up, or changed, the auto layout engine in UIKit that exposed my bug. I say it’s iOS 15.5 but it could be all 15.x. 🐞

I’m still digging. Hopefully I don’t wait another eight months to work on it again. 😳

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.

A week in the life of Stream, my feed reader.

My favorite bit to look at is what Territories folks are in. I love that my app is being used – at least downloaded – all over the world.

I think about localization often. What languages would I start with? German seems like a good start, but based on the numbers Chinese would be a better bet.