I must confess, I had given up. Not only my work but life in general. I had quit all my clients and abandoned all my apps. Cut out from the world, I barely spoke to the few friends I had left. I was in a very dark place, from where I thought there was no way out. It was only suffering in store for me, until I would eventually die. I had been ground down to gravel and dust. There was no dreams left, no hope only darkness. 

For how long could I hold on?

But life is wonderful, and it had a surprise for me. That no matter how long it’s gone, how wrong you’ve been, how many mistakes you’ve made - it is never too late to turn around. To start fighting for yourself, and for your life. I feel almost religious when I think about the enormous difference it is now from then. She came to me like an angel lighting up the world and showing me home. She made me see I have a worth. Reminding me of what is meaningful in life. She taught me what true love is. It is nothing like they tell you. It is worth all the struggles.

Now there are possibilities instead of obstacles. Life truly is wonderful when you find it. It took 43 years for me to realise what life could be, and since I never gave up I was rewarded with more I could imagine even in my wildest dreams. Perhaps that was the reason I didn’t fight hard enough, since I didn’t think this was possible. If my younger self could read this, or if you are struggling in a similar way: Don’t accept a bad situation, life can turn around in a second. Only surround yourself with people who care about you, find new ones or focus on the good ones. Just leave the others behind, don’t spend time thinking about them or try to get them to ask for forgiveness or do whatever it is that you want them to do. Focus on yourself instead and walk your own path. But most of all, never give up. It will all be worth it, in the end. True love will find you in the end and you will know just who's your friend. Everything else will sort itself out.

Now we have been married for 2 years, it has been a dream come true. Whatever happens now, I will die a happy man.

A lot have happened to the greatest Feed reader of all time, but I have been a bit shy about it. I have basically not told anyone, and that is not great marketing.

This latest release is just a patch-version fixing a bug where your Settings could not be saved. A tremendous blunder on mu part, but to my defence it only happens in certain conditions, which avoided my testing. Thankfully a dedicated power user alerted me of the error and I could fix the bug the same evening.

Before this update Feeds has gotten plenty of new shining features:

1. iPad support is back! And now with windows in iPadOS 26, things are really great.
2. Smarter, faster and more efficient download manager, that keeps all your feeds streaming into the app at lightning speeds. Did you ever wonder how Feeds can download so many articles from all your sources so fast? And not do any of them twice? It is not a miracle but a sweet and lock-free coding comfort called structural concurrency. I will not bore you with any more details!
3. A completely new parser, that is more capable and stable, allowing for brand new ideas of development in the future, and since it is much easier to work with (simpler algorithms), errors and bugs are easier and faster to squash.
4. Improvements how SwiftUI is used, eliminating unnecessary redraws making scrolling smoother and everything overall faster and more delightful. There are still more optimisations coming in the future, all is not done yet!
5. A whole new database engine which is a delight to work with. I will post endlessly about this one.
6. Tons of minor fixes and improvements that is too much to talk about.

The app is over 10 years old so it had a lot of legacy that needed taking care of, and now that is done. It took me a while, but the new foundation will stand for another 10 years. The mission now is to spread the word to get users up to a decent level. Would you like to see more new features? Tell your friends about Feeds!

Are you still not blessed with the wonders of having an app that turns the web into feeds? Take a look at this article from Nature about how neurons form in the brain. If you are reading this on an iOS device, Feeds can download automatically for you. No need to go to the appstore, just start reading! If you like it, you can just keep it and let Feeds fetch new articles as they come off the prints!

You can try a beta version here: Testflight link is here

But they are in a way correct. Here is the full story:

The app has a growing time line of due-dates, putting the widget on your home screen allows you to avoid the need for alarm/notifications. When switching apps it will be clearly visible what you have coming up or if you have forgotten something.

While waiting many years for someone to build it, I finally gave in and just build it myself. It is such a simple idea, with one clear and obvious goal that I really thought someone else should have built this already. But I found nothing, and since I needed it - I had to build it.

Now there are two questions we need to consider at the same time:

1. Is Gentle Reminders a duplicate or too similar to other reminder-apps? Then is it really wrong to reject it?
2. Even if Gentle Reminders is too similar to other apps, should appstore review-team decide if it is allowed to exist, or should the market decide?

They are not entirely wrong, there are hundreds of reminder and todo apps out there, and if I was reviewing all of them I would also be hard pressed to see the difference. Especially when you don't care about this specific issue you don't have yourself. That's why appstore review is such a terrible idea. By the very nature of being humans, they can never make the right choice. Apps that spam the store or hide their true functionality will get pass a human reviewer, but when rejecting based on opinion you just won't have the full picture and will not be able to know if that opinion is valid. Only automatic detection should be present, and those have at least a chance to detect nefarious behavior.

The bottom line is that if I want to publish something that Apple see no value in, no matter how pointless or meaningless it might seem to them - I should be able to do it. If they don't want it in their store, allow direct downloads from the web then, problem solved!

Let me hammer in the message for those of you uncertain: Building an app, running a business and doing all the other things needed for this to be possible is a mere side-quest. Fighting the app-store is the big challenge, and that fight never ends. Every update is a risk of capsizing your entire business. This particular app will of course not matter to me personally, it didn't take many hours to make and I can still use it for myself (I've spent more time writing this and fighting app-review than coding). But what about my next idea? Or your idea?

They call the app "spam", claiming that I somehow have downloaded the code from GitHub and just re-uploaded it with a new icon. 🤦🏻‍♂️ Offensive of course, they try to provoke me into leaving the App Store and go over to Android instead. Similar to many other developers just getting too tired of Apple's attitude, we just want to create great things and see them try their wings, while Apple try to prevent us. Will they succeed?

Anyway you can see for yourself, try out the beta: Testflight link is here

There was a time when new todo-apps was launched on a regular basis. And there are many, countless, apps and websites that give you a todo-list of varying fashion. Perhaps the most popular is Jira, a collaborative list with tickets that can be assigned to GitHub pull-requests and grouped by sprints (among many other things).

Horribly slow and bad UI per big-corporate-standards, of course. We use it in my daylight-job, and I brought up the idea of switching - and everyone seemed to hate the idea. ”This is the best there is”, ”There is nothing like it” was a two of the comments I got.

Should I build a collaborative todo-app for companies that don't suck? No, but someone should, and it seems easy since the bar is so low. But how should anyone convince the world of their product, trusting it enough to switch from something known?

This is the main pain-point for me at the moment, and sadly it affects all my apps and creative endeavours. I am suffocated and cannot be heard. It feels pointless to try anything since I'm voiceless. It does not matter how great anything is, since it will never be seen by anyone and never heard by anyone. I can scream into the void like this but it will never amount to anything.

I want to have a voice, and I want even the maker of todo-apps to have a voice. I want great ideas to be heard and shared.

When building a framework with functions you can't use in an App Extension, like a ShareExtension or WidgetExtension. Wrap that function or class in an @available like this:

@available(iOSApplicationExtension, unavailable)
func notInExtensions() 
{
    if UIApplication.shared.delegate == nil 
    {
        print("No delegate")
    }
}

Then create a custom Swift compiler flag "APP_EXTENSION" for each extension, and use it like so:

if APP_EXTENSION
    // do whatever else the extension should
else
    notInExtensions()
endif

Nothing more to it!

This is an old post I wrote many years ago, when my second child was still a baby. I don't know why I never posted it, but probably due to the stress-levels were through the roof. Having babies and running your own business is hard. Having babies and a regular stable conflict-free job is hard enough. Make sure to take the time to saviour those precious moments, this is what life is about. Anyway, here is the original post:

Programming takes a lot of your brain-activity. You build up these virtual worlds and let them run inside your mind. This is quite natural to all humans, think of a story - Hansel and Gretel, now you have just done that.

The tricky part is to read that story out load while at the same time doing other tasks. E.g. reading this post while telling that story. Seemingly easy at first glance, but actually almost impossible. None of those tasks are particularly hard - they are just hard to do at the same time. You will end up pausing one task to do the other, and then switching back and forth as quickly as you can - stuttering and humming as if you have a difficult time remembering the story.

This is the best I can explain it, trying to debug code while putting a child to sleep. None of the tasks will be enjoyable nor done properly and the stress levels just rises. So do one thing first, then the other. Don’t fret about work, even if those children depend upon it. Being healthy and alive is worth more to them.

1. Start by creating two frameworks, one as a separate project for code you share with other apps (which code can be compiled independently), the second as an additional target for files you won't share. The Swift checkbox should be checked if you will ever use Swift, now or in the future.
2. Make sure the checkbox for App Extension is checked.
3. Note that Objective-C can/should only use Swift in their .m files. If you try to import Swift classes from frameworks into a .h file you will spend several hours regretting that decision. Import an intermediate protocol or similar instead.
4. To use Obj-C files FROM Swift, you need to make their .h files public (in the file info sidebar), then expose them in the frameworks umbrella header.
5. Now starts the fun task (sarcasm) of splitting your app into these three sections, stuff that is imported by the appDelegate or uses UIApplication remains in the app, everything else goes into these two frameworks depending on usage.

Now you are done with stage one. Not much “architecturing” at this point. But you have already gained two great things:

1. Speed when having App Extensions is multiplied. Just having extensions causes everything to recompile once for every extension - in addition to the slow compile times of Swift!
2. Testing is now instant! Frameworks can be tested without launching the app, so tests you have moved or will write are going to be lightning fast! If you need the bundle or the app, you will need to rewrite some, but it’s still doable (more on that in a future post).

Stage two, splitting what's left of the app. Since backgroundTasks make use of the UIApplication, all long running tasks are probably left in the app. Separating these tasks can be tedious but there is a shortcut! NSProcessInfo can also disable termination, but it has no callback. So you better make sure you only need those few seconds you get. Otherwise you will simply need to leave the classes in the app, splitting them into two classes is quite pointless. If you are using Objc, you can trick the compiler into importing UIApplication only when it exists. Like so:

static Class uiApplication = NSClassFromString(@"UIApplication");
[[uiApplication sharedApplication] anyFunction];

Stage three, splitting the frameworks into smaller frameworks. Having lots of Swift really takes a toll out of your patience when compiling, especially with SwiftUI and switching between testing/running - three tasks that keeps rebuilding your code. Here you can go many routes, but what I've done in Feeds is to layer everything, larger UI-classes and Controllers on top, data-objects/models below, and on the bottom there are standalone UI components, utilities and frameworks shared with other projects. The important take-away is that the framework above can use those below but never the other way around (since we don't want circular dependencies). In addition it forces a strict separation of UI from data, which should not affect anything as it should always be separated. With this setup it is also easy to split up UI-frameworks when compile times for those grow too large.

In my experience it seems that SwiftUI and Combine benefits heavily from small structs, compile times seems to improve massively when split into smaller pieces even inside the same framework. So if Swift compile times is your main problem that should be the first order of business. I have not measured it but I will eat all my hats if I'm wrong.

Side notes

Swift in frameworks tend to become public all over, if you have a tight relationship between two classes/structs in separate frameworks at least one will need to become public. This degrades compile times since Xcode now needs to make sure the code is sharable (probably due to ABI-stability). This makes it important that classes that uses each other stays in the same framework. Also it makes it clear that frameworks is not a silver-bullet that solves all your problems, it can even make things worse. Secondly dynamic frameworks slows down your app's startup, so you should be sure that it is necessary when creating new ones. You could use static frameworks instead, but these take longer to compile. One could imagine a situation where you switch between static and dynamic before building for the App Store, but since this is not done automatically and since Apple recommends dynamic frameworks I assume there are more to the picture than just compile and startup times.

If you know the answer to that riddle, or have a hunch - you are more than welcome to send me a suggestion: @olof_t

1. First of all it can create a feed from any feed-like webpage, it doesn’t matter if RSS is supported or not. This is more useful than you think since some sources strip their articles, sometimes only the header remains, and sometimes only certain articles are part of the rss-feed.
2. AI-sorting: Information overload strikes you quite soon after adding ten (or so) feeds. Other apps try to solve this by forcing users to categorize every feed to make users sort items manually. Quickly your leisure time becomes filled with needless chores. Instead Feeds sorts articles by your preference, things you really like first, and then things you usually read. Last comes what you probably don't like (according to the AI). It is automatically trained, all you have to do is read normally and it will learn by itself!
3. No chores to perform! Everything in the Feeds-app is built around leveraging computer power to automate tasks. Humans should never have to do work unless strictly necessary. That’s why Feeds has no folders to manage, no categories to juggle and no read/unread markers. Everything is laid out in an overview, one tap to read and the rest follows below naturally. If you want to read an old article it stays in the “old” section for a few days (or just search for it) - but if you don’t care for the article it will automatically disappear. Nothing needs to be done!
4. Full RSS article downloads, when you prefer the curated RSS-feed, but want the full content and not just the excerpt. Feeds got you covered!
5. Everything inline and new content below. Articles expand inline to eliminate the need for side-scrolling/swiping, and new articles always follow below! One can just continue reading!
6. Super fast full text search. It has happened to me a million times, a discussion comes up and you know you read about it but don't remember when or where - just type a few words that you do remember and violá - there it is!
7. Mute topics you don't like. Phrases that comes up on a regular basis that you don't ever want to see, not even last - mute it. It will still exist in the feed if you change your mind, just one extra tap away. Regex phrases are also supported!

If you haven't yet tried it, now is a good time to download Feeds and take it for a spin!

Release day went great! A few bugs were found, and I could quickly release updates to fix them. The feedback has kept pouring in and I really like it! A few years ago I dreaded the flood of emails that came after any updates. Now it felt really encouraging, perhaps I've turned a corner?

The bad news is that marketing is really hard. No-one wants to write about it, and few are writing about apps at all. Every download I've got is basically from someone I know or have reached personally. I simply need to learn marketing in order to continue this kind of work. So this is what I will write about, technology and marketing - what works and what is a waste of time. If that sounds interesting:

Follow me in Feeds!

Welcome, and follow my journey. If you would like me to try something and see what effects it has - I will do whatever you say (as your humble servant) and share the numbers bluntly! 😬😮

Talk to me: @olof_t

So what is it and why is it so much better than anything else? Let's take a quick tour comparing with my favorite adversary CoreData!

When building AutoDB I wanted something that was as fast as possible, avoided all the extra work/chores and problems other frameworks had but still didn't compromise on power and features. It also had to be automatic... Apple's CoreData is not thread safe, and that was my main problem. I never understood the reasoning behind this, but if you wanted to populate your GUI with info from CoreData you first had to fetch the data in a background-thread and then fetch it again in the main, GUI, thread. This is such an inconvenience and if you do something wrong, the app will crash, corrupt the data, and in the worst case the app itself will refuse to ever launch again! This is such a terrible design, I can't understand why people put up with it, and I didn't - so had to build something better.

I wanted the data to be accessible from all threads, as regular objects. There is no point in having strange thread boundaries, it only complicates things. Additionally, having regular objects have the benefit of making uniqueness easy. I decided early on to always use a 64bit int as an id, so when fetching from disk I can easily determine if an object is already fetched and exist in memory or not. The system keeps one list per class with weak references, its fast and easy to check if an object exists or not. Then it can be freely used by any thread in the whole app. This removes a lot of pointless complexity like determining what changes are the "true" changes. Imagine that you have two different views in your app, loaded at the same time exposing the same object. Both change the object - and later saves the changes to disk. What should happen? In CoreData you need to build specific code to handle this case, since those two objects are different but are stored on the same place on disk. In AutoDB they are the same object so if you change one parameter in view A, and another in view B, both changes are already visible in both locations. There are no conflicts and only one save-operation is carried out when saving to disk.

Another unnecessary hassle is migration. When you add properties to your classes, the tables need to update accordingly. In CoreData you need to manually perform a weird migration which is loading all data into memory, then saving them to disk using the new format. AutoDB just updates the table in-place and leaves you alone. Only when modifying the type of a column, will AutoDB need your manual help, since it can't know for sure how you like to transform a string into a date. Adding and removing columns and tables are also super-fast operations, even with heavy usage you won't notice the delay.

Automatic, so what does that mean? It means that if your data classes inherit AutoModel all of this comes for free.

This is all I will write about AutoDB this year. It is available here: https://github.com/AutoDB/autoDB. It was nice to get these thoughts down, have a good day! 😄