Rob Fahrni

Using the Beta

I’ve been using Stream for Mac in its default mode for quite a while now and I really love it. I can see things I need to tweak but the overall shape and stability of the app put a smile on my face. It’s simple, as intended. Perhaps too simple for some but I built Stream to scratch my own itch and I hope others will enjoy it as well.

The default mode is, like the iPhone and iPad versions, a timeline like Mastodon or Bluesky. There are no unread dots in the timeline so you don’t feel compelled to read everything. It’s meant to be a casual timeline. If you don’t feel interested in a certain headline, just keep scrolling.

If you’d like to remove a feed just display the blog list by doing Cmd+Ctrl+s to show the list, remove the feed, and do Cmd+Ctrl+s to hide the blog list. You can also show and hide the blog list by selecting View > Show Blog List or View > Hide Blog List. Easy.

I don’t think I’ve mentioned it but you can navigate up and down the feed items list by using the j and k keys, yes vi inspired, and you can press the space bar to do a page down in the article you’re viewing, doing a shift+space will go backwards. I still need to add code to detect when you’ve reached the top or bottom of a page so I know to jump to the next feed item for you automatically.

For a while I was pretty happy with the overall UI look and feel. That feeling has now disappeared and I think it looks kind of meh. I’m gonna work on that. It needs to be better.

Sync

Folks are going to hate, hate, hate, the lack of syncing between your devices. It just doesn’t exist yet. When I originally started Stream I wasn’t happy with the performance of CloudKit. I don’t know if it’s any better today but I have to support it. It’s on the list of things to do once I complete the initial Mac release. I kid of have to gut my data persistence layer and make it work with CloudKit, which I haven’t invested any time in, yet.

I’m ready to get the ★☆☆☆☆ reviews with the “This app sucks, it doesn’t even sync your data!” That’s fine.

There are great alternatives

There are many great choices out there for feed readers. Apps like Unread, NetNewsWire, Tapestry, and Reeder are great choices for more advanced feed readers. I will certainly support some things they support and hope to give you something different. We’ll see. 😄

Thank you

As always I’d like to express my gratitude for everyone who’s ever downloaded the iOS version of Stream for their phone or iPad. And I can’t thank everyone who’s supported me by giving feedback or helping me with a code problem. You’re the best. Thank you. ❤️

Oh a whim I applied for an iOS dev job with Starbucks. I’ve always liked the app because it’s super easy to use and gives me exactly what I want from an app: a way to order and a way to pay. Simple. To the point. It could be a much smaller app, but it’s one of a group of useful ordering apps I call Marketing Apps.

Anywho, I did not expect to get a call and I didn’t. Just a nice rejection email, which I was grateful for because it’s nice to have your rejection acknowledge.

What did I get done today? 🤔

I did a bunch of little things to make the app have fewer rough edges.

• Removed the border around the blog list (Thanks, Lucien)
• Updated the selected Blog in the blog list to use white text
• Rounded the corners of the selected blog item in the blog list
• Adjusted the position of Blog list items to have some space around them
• Set the divider between panes to be thin
• If one blog is select and you refresh it, we only refresh that one item (Thanks, John)
• Updated the All and Read Later icons to have some color

I tried to fix an issue that causes the preview text in the feed item list to sometimes display only a single line but the text view is three lines high. Weird, I know. Sometimes it will display a single line but the text could be three lines high. I know this has something to do with cell recycling. I tried some recommended things to get the cells to resize their Text but no luck yet. I’ll get there.

Another thing I need to do to fix this is decode any HTML included in the feed and strip everything at the top that’s not a paragraph marker. What happens now is you won’t get any preview text because the top bit is an image or other HTML I’m not accounting for.

I didn’t get around to fixing OPML Import so it displays some sort of progress indicator while it’s working. I’m thinking about displaying a simple spinner with text to the right that reads something like “Importing: [blog name goes here]” in the toolbar. I think I’ll hide the refresh button and the Stream title text and replace it with the spinner and import text. That sounds good in my brain at the moment. 🧠

Technical Foundation: Built with modern technologies — Electron, React 18, and TypeScript

If I’d had a mouthful of coffee I’d have spit it all over my display. 🤣

I didn’t realize Electron, React, and TypeScript were “modern” technologies for building desktop apps?

But… these technologies seem to work and there’s an abundance of web developers who can step right in to create a nice desktop app.

I guess I have to face it. The web is now the desktop.

The Iconfactory Blog

Linea’s interface has been updated to feel right at home on iOS 26 and Liquid Glass. Today’s update emphasizes your canvas while keeping tools just as accessible and intuitive as ever.

Redesigned transformation handles make it more obvious how to scale, rotate, and adjust your selections, reducing friction when refining your work.

Congratulations to my friends at The Iconfactory! 🥳

There are four apps I absolutely love from The Iconfactory; Wallaroo, Tot, Tapestry, and Linea Sketch. I admit I don’t have Linea Sketch because I don’t have a modern iPad, but if I did I could see using it for block diagrams of all kinds.

In fact, I believe, The Iconfactory crew should do Linea Diagram, a Visio-like diagramming app for Mac and iOS. (Yes, I’m biased because I worked on Visio for 10-years. Best job I’ve ever had!)

Then you’d have the Linea family of apps! ❤️

I fixed the issue with my Context Menu’s not working. Totally stupid move by me — I knew it would be. After my last coding session I changed a property to be “weak” because I thought it was retained somewhere else. Then I committed that change because I needed to pack up and get home. Mistake! That property needed to be retained because it was passed in and the caller created it to be handed off, it was NOT retained. What a rookie move on my part. 🤦🏻

Removed the “weak” last night and now it magically works. Oh, yeah, I also made another change. Instead of using a NIB to create the menu I did it in code and I just like that better. It was extremely straight forward and felt very natrual. Works great! 🥳

Next, the app was approved for Testflight last night and I’ve already received some very good feedback! Thanks, John! (No we’re not competitors, John’s Unread is far and away one of the best Mac and iOS feed readers on the market. Go get it and subscribe because his sync service is fantastic!)

Look, I know Stream for Mac isn’t going to be good for everyone and even some of my testers may look at it and say “This is complete crap!” But, it makes me happy working on it and I’m especially thrilled to be making my first Mac app.

It’s ok to be critical of it! I’d love to get your feedback, so if you’re using it, please share your opinion. If you’d like to see a really rough beta, let me know (if you’re reading this you’ll know how to find me!) and I’ll add you to the list!

This morning I decided to get TestFlight setup so I could start dropping alpha and beta versions of the app. It didn’t take long, which was really nice, and I’ve submitted a build for Apple to approve for testing. I’d imagine it will take some time to get through the gauntlet since it’s the first version of Stream for Mac. Fingers crossed it doesn’t take long to get through. 🤞🏼

Besides that I added a couple new menu items to the View menu and implemented them.

The first was View > Timeline which is meant to present Stream in its two pane layout with a stream of blog posts in the left column and the text of the post in the right pane. I’ve called it Timeline but I don’t like it. It feels backwards. When Timeline is selected the leftmost list of blogs is hidden so you get that two pane view instead of three. It feels backwards because when it’s checked the blog list is hidden. I need to find a better way of presenting it. The functionality works just fine.

The other menu item is called Read/Unread Dots. I need a better name for this as well. What it does is hide or show the read/unread state dots. When I originally shipped stream I didn’t keep track of read state. It was meant to make viewing a more chill experience. I had a lot of folks reach out and ask me to add that read/unread state, so I did. Now I want a way to turn them off. This feature will make its way back to the iOS App as well, probably in a new menu item or as part of Settings. I need to think on it a bit.

I’d intended to do a bit more but as I was running through the UI testing random stuff I noticed the context menu for the blog list wasn’t working. It worked just fine last weekend but not today. 🤬

I spent the remainder of my work time trying to understand what I’d done wrong. The actions were all hooked up, they just didn’t fire when a menu item was selected. I checked the NSMenuItem and it wasn’t nil and had all the menu items present. It just won’t invoke the associated action.

Depending on how those table view cells are configured I will remove the menu by setting the new menu to nil, but that’s only for the All and Read Later items since the menu items don’t make sense for two things.

The other thing I did was delete my toolbar from the main NIB. I put it back later in the day but it did make me wonder if that change had something to do with my other menus not working. Yeah, it’s a stretch since they’re in separate NIB files. But I sure can’t explain how I broke it. 🤔

Any tips from Mac AppKit experts would be appreciated. 🙏🏼

That’s all for today. It was a good start but that busted menu was a huge time sink and I don’t have an answer for it yet. Maybe I should see if Claude can fix it? 😁

Let’s go!

Today’s progress on Stream for Mac felt great. I was able to replace the Collection View item in the Blog List — leftmost column — with a native NSCollectionViewItem, which was extremely straightforward.

I also added right mouse click menu support so you can do a few actions in your blog list; Mark All Read, Copy Feed Link, View Website, and Unsubscribe. All of the actions work as expected.

Cmd+A now selects the top most item in the list — All — and displays all items from all blogs in the middle column. You can, of course, select that item with the mouse and get the same results.

The middle column adds right mouse menu support for; Copy Link, Open, and Share… All actions work as expected.

I’m showing my hand a little bit with the item called “Read Later.” 😃 Yes, I’m adding an Share Sheet Action that will allow you to not only “Subscribe in Stream” to add a subscription from the blog you’re browsing but a new item will be called “Read Later in Stream” that will stash a reference to any site you’re browsing so you can check it out later. Hey, I really need that for myself! It’s how I collect notes for Saturday Morning Coffee. For now I’m using John Brayton’s excellent Unread to do that for me. Stream needs that support so it’s gonna get it. Both the Mac and iOS versions will have it.

I still have a lot of cleanup and tweaking to do. Mostly in the area of design. I have visual nicities to add and tightening some visual elements up to make my eye happy. It’s getting there.

Some things that need fixing. Selection of a blog item currently has black text and a blue highlight. The text needs to become white so you can read it easier. I’d also like to round the selection rectangle a bit and give it some inset so it doesn’t look so sharp. They currently look like you could cut yourself on them! Same for the middle column. Selection needs some help and that includes the same rounding and inset work. Using the app shouldn’t result in cuts.

I have some nagivation stuff to add — like using the spacebar to advance an article and jump to the next one when you reach the bottom. I’ve already added vim J and K keys to havigate up and down the middle column. I’d like to be able to navigate the entire thing without taking your hands off of the keyboard. Need to add something for navigating the blog list with the keyboard, maybe D & F? Are there standards for that yet? I’ll see what other Feed Readers use.

I feel very close now. My current plan is to ship the first release without Settings, so no way to tip me. 😄 I will add that support next. For now I’m just really excited to kick it out the door. I can build on what I have from there. Once it gets out there are things I’d like to do for the iOS version and Mac version that will be shared. I need better article parsing, I rely on what the RSS feed provides and if it doesn’t provide the full text of the article, I can’t display it. In the future the app will go to the article and parse the full text if allowed.

So little time, so many features I’d love to do!

LET’S GO!

Time to work on Stream.

Code by me, coffee by Grit

grug tempted to reach for club and yell “big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!”

I love The Grug Brained Developer. Grug make laugh. 🤣

I was able to make it to the coffee shop and work on Stream today. I’ve been revisiting how to construct a good AppKit cell view — NSCellView — that does exactly what I want. And I continue to fail.

I’ve tried using constructing a cell using a NIB. It didn’t work as I’d wanted it to and I could never get it right. I abandoned that attempt.

Next I tried doing it in code. I managed to get the same exact results. It didn’t resize properly. I abandoned it.

I decided I should do it in SwiftUI. It only took me an hour or so of tweaks to make it work exactly like I wanted! Yay! 🥳

Next I had to get the little blue read/unread indicator working. I tried a lot of stuff but I couldn’t make it work driving it from an AppKit view (more on this later.)

So, I decided to give AppKit another try. This time using NSGridView in code. I wasn’t able to get the results I was after. So, you guessed it, I abandoned the attempt.

I thought I’d be clever and let Claude do it for me because I’m so darned hung up on it working as an AppKit cell.

I gave Claude a description of what I wanted, pointed it at the working SwiftUI version, told it to use my coding style, and turned it loose. At first glance I was surprised. What it built worked exactly like my AppKit versions. The date wasn’t pinned to the right of the cell view and things didn’t flow properly as I resized the cell. These are the exact same issues my hand built versions had. 😳

I went back to Claude and explained what I wanted to change and why. It went to work and made some tweaks. I thought, this is it!

Nope. Not it. Still has the same issue. The code was tweaked but I got the exact same results. 😳

I was puzzled to say the least.

At that point I was ready to declare I was a completely incompetent developer, throw my computer in a lake, and go hide away in the woods somewhere until I died.

I decided that was a little extreme and decided I’d go back to the working SwiftUI version.

Now, how do I actually get the darned blue read/unread dot to update properly?

I poked around at how Combine and SwiftUI work and how to properly expose and use a property when it updated. This time I went right to my model and made the very simple changes. Those worked as expected. 🥳

Now, to be clear, I’d tried some combination of things prior to this attempt and they all failed. Why didn’t I do it this way to start with? Well, I’m dumb, and stubborn, and wanted it to work a certain way, so I kept trying to do it my way. Sure, I used Combine and @Publish and ObservableObject, and the other macro I’m forgetting at the moment, or some other combination of those.

This time I told myself “Just bite the bullet and do it exactly like the documentation says, don’t try to fit it into your model.”

It works. I’m happy about it.

I stubbed out Command+click options on the cell and added some print statements just to make sure it did stuff. It did.

I packaged up my laptop and headed home. Now I sit here tying this up. I’ve been banging my head against a wall off and on since December of last year. I am an idiot and maybe I should quit?

Problem is, I really want to make this app. 😁

Time to hit publish and go mow the lawn, where I’ll think about my next steps for Stream for Mac. For the time being I’m freed of that burden I carried for so long.

Now I can do the features I need to ship the first release.

That is a good feeling. 👍🏼

Out of curiosity I just configured a new MacBook Air. I’m pretty sure it’s the one I’d buy if I were in the market for a new laptop.

Here’s the configuration:

• 15in.
• Sky Blue
• 32GB Memory
• 1TB SSD
• Included power adapter
• Yearly AppleCare+

Total price: $1,899

My work laptop is a 16in M2 MacBook Pro with 32GB memory and 1TB storage and it’s a great computer. Fast and reliable.

The Air would definitely be enough horsepower for my app development.

Sitting at Grit — my favorite coffee shop — sipping my mocha trying to decide what to work on.

Stream for Mac, Stream for iOS, or Thunder Chicken?

It should be Stream for Mac. I haven’t worked on it in a while because I’ve been working on Thunder Chicken.

I’ve thought about doing a German localization for Stream.

Adding a right mouse action menu to the Mac version of Stream, and whatever else I can complete.

What about having Claude create an NSCellView for me that sizes properly when the column it’s in resizes. I could never get this working properly but did it in SwiftUI rather quickly.

How about completing the first full implementation of a network client for Thunder Chicken? Get posts, create posts, update post, delete posts, etc. I have an abstraction so I can support multiple blogging platforms.

Oh, I forgot about Arrgly. It’s my link shortener that uses YOURLS for its backend. I have a new SwiftUI version of it I need to finish off, just because.

Decisions, decisions.

This would be a welcome UI change in macOS. I keep thinking about older operating system UIs and I miss that more chiseled look. I’ve also always loved the color versions of Mac icons and the angle they’re drawn.

I think I’m just feeling nostalgic but I’d love to see a modern take on this older MacOS look.

I have such a huge list of things I want to add to Stream. Like full page parsing and stripping of formatting, fix some things that annoy me, syncing, connection to feed services like feedbin, recommendations (curated and LLM recommended), a Mac version, and the list goes on and on and on. 😃

I’d done some work on a function last week that determined if a certain permission level was valid for a particular type of user account in our app. The requirements depended on multiple different factors including account type, language, and some other sub data types. I paired with some other devs on the team because they knew way more about the account types than I did, yes, they were convoluted and a few special cases had to be accounted for and even included a check for language spoken and region of a country.

This function had been a lot more straight forward but we were expanding the application to work with more account types so the unit test requirements doubled. When I went to update them I was struggling a bit, remember, I’m using TypeScript and I’m still really bad at it.

After scratching my head for a bit I opened Cline in Visual Studio Code and asked it to “write unit tests for [filename].ts” and it got to to work. It churned away for a while then started outputting new code. After checking some outputs and clicking Save a few times my brand new unit tests were complete.

It worked. Color me shocked. 😳

I can now see doing this for most, if not all, of my unit test needs on this project and probably others. As much as I enjoy writing unit tests, no, seriously, I do enjoy it, this saved me quite a bit of time. Just incredible.

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.

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

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.

At work we’ve started using Bruno. It’s nice but it’s also an Electron App. I’m already learning React Native on iOS because we are getting a lot of requests for applications written using React Native. We build apps for clients so it makes sense for their apps to be written once so they work on both Android and iOS. They get their money’s worth, I suppose. It’s all about squeezing more out of us. But what does that say about craft? To me it says it doesn’t matter. We’ve fallen into the Accenture trap. We are hired guns who need to pound out code everyday at the fastest possible pace, with high quality of course, and use the lowest common denominator toolset. 🤢🤮

Anyway, I’m feeling a bit spicy this morning for some reason. I really need to improve my SwiftUI and pound all the new concurrency stuff into my tiny brain but I’m torn because to be useful to my company I need to become a React Native expert.

Guess I’ll have to use Stream and Top Secret Project to learn SwiftUI and Swift Concurrency. 👍🏼

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.

I’ve neglected Stream for far too long and I don’t know when I’ll have the gumption to get back on it. Learning AppKit has been a slow and arduous process. I really hate when I suck at something. I know, I know, doing the work will make me better but I just don’t have the energy that 20 something me had to stay up all night learning and doing.

Once of these days I’ll get it finished. It may take years to get there but I’ll get there, I hope. 🤞🏼

Of course finishing off the 1.0 of Stream for Mac would allow me to work on Rooster, which is a new codebase and 100% SwiftUI. 😄

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.

Since we can use Swift to write code for Windows I’m excited to give it a try.

I’m hoping I can bring over all of Stream’s model, network, utility, and view model code over without changes, or perhaps few changes?

The other thing I’m thinking is, I should be able to port my C++ framework for building Windows apps to Swift. That would be something really special and would allow me to do a full version of Stream for Windows. Heck, if my shared code comes right over and I can rebuild my Framework in Swift, I should be able to do a Windows release pretty quickly.

Of course I really need to focus on the Mac version first.

Hey, Microsoft, can you make Visual Studio support Swift as a first class citizen so we can build and debug using it? Please? 🙏🏼