Rob Fahrni

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.

Welcome to the modern definition of a “mobile developer.”

If you know JavaScript you’re golden. It’s no longer about native apps, it’s about leveraging web tech, and getting the most bang for your buck.

Learn the JavaScript if you want to have a job moving forward. Personally, if I were to use a cross platform development platform I’d probably choose Flutter.

I feel like I’ve been working on this app forever. 😀

But, I haven’t. It’s been a couple years of fits-and-starts. The last TestFlight build I sent out was, I believe, back in late February.

I only have a few new items to add then it’s all about bug fixes.

What’s left?

Import and Export OPML

I have the core of importing and exporting working fine. It’s what I worked on today.

The one stumbling block I have is where it fits in the UI, like it’s a little thing. I have some ideas, of course, but I’m not thrilled about any of them. I’ll probably pick the least icky idea and do that.

Once that’s done I’d imagine the Export feature will live next to it.

Sharing

This goes two ways. I’d like to add an extension that will allow someone to Add to Stream from a web browser and I’d like to allow folks to share out of the article view. This should allow folks to start a blog post of their own or post to their favorite social media site.

Nice to haves

Extra Icons

I have some beautiful icons to share with everyone and I really hope you all enjoy them as much as I do.

Tip Jar

I’ve struggled with this one a bit. Stream is going to be free. It’s not going to be something folks just gotta have. I did this for me. I wanted an app that was simple and felt more like a Twitter feed. I think it hits both marks.

The reason I’ve struggled with the idea of having a tip jar is I don’t want folks to feel like they have to pay anything for it. I would appreciate it but it’s not necessary.

Wrapping up

I have a few bugs I’m aware of, mostly around stripping of HTML tags.

Thanks for following along.

Time to get in on the action.

Here goes: Custom Watch Faces, iOS stability and performance improvements, and macOS stability and performance improvements

That’s it.

I’d really love to have a Dumbledore watch face.

I’ve been thinking about models for making a little money from my iOS apps. I only have two at the moment and they’re both free on the App Store. Neither app has been downloaded in large quantities. RxCalc – a pharmacokinetics calculator – has around 10,000 users and Arrgly has a super tiny user base – I built it for myself and decided to share it. And, yes, I know the name and UI are completely goofy.

I’ve been working on a new application called Stream and I’ve gone round and round in my head about monetizing it; should it be FREE, free with in app purchase, free with tip jar, or up pay once up front?

So many choices.

My initial thought was FREE with an In-App Purchase Tip Jar. This would allow me to, hopefully, make a few bucks from it and I could reward users with additional icon sets and color schemes.

Then I happened across Ko-fi. It looks like a nice way to make a few bucks off of my hard work and not give Apple 30%. On the flip side I wonder how much I’ll lose because folks have to visit my site to tap on the Ko-fi button to support my apps.

If anyone reads this, and knows a little about Ko-fi, could you let me know if it’s something I could, or should, use to support my apps?

Just send email to rob.fahrni@gmail.com.

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.

Do all Apple related podcasters believe every nerd carries around the latest greatest iPhone?

I’m a professional iOS software developer. Have been since 2009. Prior to that I made my living writing Windows and Linux based video viewing workstations. Prior to that I worked on a an extremely popular Windows desktop drawing and diagramming software. I’m approaching 30-years as a pro.

I carry an iPhone 7.

I’ve been an iOS Developer for just over 10 years now - 30 years of professional experience overall - and I still suck at Interface Builder and Auto Layout. 🤪

I’ve been able to work a little bit on my beloved side project, Stream. For those not following along, or those that have forgotten, Stream is my Twitter-like News Reader.

Life changed pretty dramatically for is over the past nine months or so. Our daughter, grand daughter, and son-in-law moved to the east coast. Kim and I had a two year plan in place to move back east so we could be near them, living in California doesn’t make for easy day trips to visit when we want. That is another story all together. Suffice it to say serendipity struck and we moved the timeline up, way up.

We arrived in Virginia November, 1 and moved into our new home. Yes, it was extremely fast. All the work surrounding the move meant I really needed to focus on all things related to the move and let the side project sit. Now that we’re settled in our home and I’m settled in at work I finally got Stream out of moth balls and worked on it a bit.

Crashing Sucks

I had sent out a few TestFlight builds to folks but I knew where the ugly parts of the code were. I pushed it out way too soon, I realized that after a couple builds. I should have finished all features before user testing became a thing. Live and learn.

I found two things that bugged me more than anything else; the app would crash on occasion and syncing feeds was way too slow.

A couple weekends back I was able to plant myself on the couch and work through the performance issue and the crasher. I can thank Brent Simmons for the most significant performance wins. His blog posts, tweets, and Slack messages about feed reading and general Cocoa Framework oddities have proven invaluable. I only hope I can pay his kindness forward at some point. Thanks, Brent.

Ok, on with the wins. The first two tips I picked up.

Handle 304 HTTP responses

This one was an instant performance boost if servers hosting feeds actually return it. If you’re making 100 network requests to update your 100 feeds it can be kind of slow to parse all the resulting data. But what it you don’t need to parse the results? Right! The data you don’t have to parse makes your code faster. Imagine that!

Create a hash of the response data

So, what if you ask for feed data and it hasn’t changed but the server doesn’t return a 304 indicating it hasn’t changed? Well, you create a hash of the response data and keep it for later. Next time you grab the feed, hash it and compare it to the hash you created last time.

One more thing

After reading Brent’s piece about KVO crashes I decided to stop using NSOperation and NSOperationQueue. I was only using it so I could create dependencies that would allow me to have a final operation that updated the UI’s data source. Now I don’t do that. I just rely on URLSession and URLRequest to do the job.

Not done

I feel a lot better about the performance but I know there will be more changes down the road. Moving forward I need to focus my effort on finishing the UI and adding some niceties like a share extension to add a feed and things like dark mode support. There are other things I’d like to do as well. Least of which is building a Stream Mac App. 😀

I’ve adjusted my personal expectations to ship before WWDC this year. Let’s see if I can make it.