NetNewsWire is another great example of quality open source Mac applications that don't force my laptop in 100% CPU utilization, especially for RSS readers.
Given that the author did a recent article about technical programming interviews, I'd pretty much see this article as enough evidence that the author here knows their stuff in data structures appropriately and also optimising apps beyond his own ones and would bypass the programming interview stage anyway. (All this code is open-source in NetNewsWire).
Wow, I had no idea NetNewsWire had become free and open source. I stopped using it after v3 (because v4 removed some AppleScript functionality I depended on, although I now can't even remember what it was) and completely missed the news that a free v5 had been released, and open source to boot. This is fantastic!
I love the detail in the post! A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? Maybe the higher level tooling didn't exist when they started working on the platform so they had to pick things up out of necessity?
> A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand?
I'm not the author, but I've got this facility as well. I guess part one is to have motivation --- it's hard to know what to research before hand[1], but if you've got something that is actively too slow now, that gives you a clear direction. Part two is not being easily satisfied that things are fast enough, or fast as you can get. There's almost always a way to make UI faster, it's just a matter of what needs to break to make it happen, sometimes it's abstraction layers. You can go back in time and look at 1980s UIs and while some were slow, many were super fast, and yet the CPUs were slower than dirt compared to today. We're often marshalling a lot more data and pixels, but it just shows than processing everything in time for the next frame is a reasonable target. Learning to use the profiling tools available is a good concrete first step.
[1] But, don't let that stop you from research into things that are interesting to you, or seem like they might be useful. Knowing something can be done is immensely helpful to doing it, even if you don't remember how it was done.
Yeah, it’s impressive indeed.
Simmons has been developing macOS applications for a long time, e.g. when he worked for Omni Group. Here’s an interview from 2003 where he talks about an early version of NetNewsWire: https://daringfireball.net/2003/03/interview_brent_simmons
There's no black magic here. Everything you see here can be found by running the profiler and reading the docs. I haven't been a Mac developer nearly as long as he has, and almost all of these are things that I do.
Aside from the specific optimizations listed in the article, and caring about improving round-trip times for remote API calls in general, the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast.
Apple's APIs for macOS and iOS are simply better than those provided by either Microsoft (for Windows), Google (for Android), etc. Apple's APIs are, for the most part, very well-thought-out; their engineers have put together fantastic layers in the operating system and its UI components. The primary reason so many apps perform poorly on Apple platforms is because those apps were developed using 3rd party cross-platform tools (eg. Electron, or making an iOS app with webviews rather than native elements).
Developers who make efficient use of Apple's APIs, and who spend time to reduce their backend response time on remote API calls, will always produce an amazing product. The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage. It's such a breath of fresh air to witness.
Remember that Core Data manages a graph of objects: it’s not a database.
and therein lies the primary reason that I try to never use Core Data if I can avoid it. I almost always want a database. I almost never want to manage a graph of objects. If the backends I spoke to were also organized as object graphs, maybe I’d feel differently about it.
I always thought that using it as basically the db or cache for remote API was a terrible misuse of CoreData, but a graph of objects does come in handy when driving complex UIs.
These all have a lot more network overhead than an RSS reader that only has to periodically fetch a bunch of xml files. I feel like optimizing these kind of apps is a whole different problem space and a "native" app is probably not going to change that so much.
I wouldn't advocate for slower software, but is all of this really necessary for a fast RSS reader? My RSS reader downloads the entire XML file as blob, parses it into an array of structs, then walks over the array looking for new links. It's not particularly slow. I can't imagine it would be worth optimizing this aspect of the code base.
I don't know if it's "necessary," but you can really see the speed difference between NetNewsWire and, say, Reeder on the same hardware. It's not that Reeder is slow, it's that NNW is just really fast.
> I can't imagine it would be worth optimizing this aspect of the code base.
Well, this is the code path taken when the news reader is starting up or refreshing, right? It feels to me like that's the most important place to optimize an RSS reader, because it has a direct impact on the time between when the user clicks the "Refresh" button and everything is updated. Even if the user doesn't actually need to sit there and do nothing when it's updating, if updating takes 3 seconds instead of 10, it makes the whole experience feel much faster.
Frequently, yes - profiling is important, of course, but feed readers disproportionately have power users who subscribe to many feeds, some of those can be very busy (e.g. monitoring or saved search services), and some people want a fair sized archive. When I first open a desktop reader app, I’m asking it to poll hundreds of feeds - it’s not a server running constantly - and easily many tens thousands of items before filtering. That means lots of repeated updates - and wanting that not to impact whatever is happening in the foreground.
Not critical but definitely noticeable - kind of like how the Atom editor had a bad reputation for input latency even if it was still usable, coloring your perception of the entire app.
No optimization is worth the effort before profiling.
If they found out that these operations are responsible for long enough delays, or high enough energy consumption spikes, it would make all the sense to optimize them.
RSS applications all have a fixed feature set. Subscribe to feeds, check feeds for updates, organize & sync data for multiple clients, and present user's reading list to the screen. There are several RSS readers that all tick these boxes.
NNW is clearly a labor of love for the author who has been involved in macOS development and RSS for a long time. NNW is unabashedly Mac-only and unabashedly fast. I love reading about people's passion projects.
I just discovered the iOS app for NetNewsWire and I am blown away that it is only 7.5 MB in size! I did Xamarin development for a while; a blank hello world application is about 45 MB. Kudos to the team!
What is a good use case of such "free" mobile app if the sync feature is behind a third party paid service? Am I expected to always check my feeds only on my mobile? How useful is that?
As much as I would use NNW right away but it isn't really a useful service at this point in time.
Any particular reason why this is a local (destop/mobile) app? I use Feedly and performance was never an issue, with the bonus that content and status is synced everywhere.
I don't want a website open all the time. I don't want to have to be connected to the internet to read my catalogue of saved articles. I want native performance, not "good enough" or "not really an issue" performance. I want 100% integration with my system; I want AppleScript-based automation. I want my system's accessibility settings to determine how I use the content, not depend on how some website's CSS handles my use cases — not that a lot of websites, particularly SPAs, are made such that VoiceOver can deal with them.
Those are my reasons why I'd want a local desktop app, anyway.
The whole point of the app is to provide native macOS/iOS UI. I use Feedly to sync with NetNewsWire on iOS (and will on the Mac once it's supported, supposed to be in next update).
Developer preference. Simmons is famous in the Indie Mac world, even though a good portion of his career has been at companies. He’s still most well known as the guy who developed the original NetNewsWire before selling that to NewsGator, a kind of Feedly before Feedly existed, and then after some events I really can’t quite remember, taking it independent again and eventually selling it to Black Pixel who gave it back. I believe they were acquihired a bit after that if I’m remembering correctly (but don’t quote me on that), so it might have been because they knew they were soon to sell.
This particular iteration of NetNewsWire only shares the name. NetNewsWire 5.0 was originally being developed as Evergreen because Simmons got interested in making another RSS reader. It would never exist as a web app simply because he’s not the type to want it to be anything other than a native app.
Less well known is he was also the original developer of MarsEdit before selling to Daniel Jalkut. MarsEdit to write blogs, NetNewsWire to read them.
I used to use NNW but one time my 2 year old kid just did a one quick swipe on my phone’s screen while NNW is open and just deleted the whole content. I’m not sure what gesture made it happen but I switched back to Feedly.
[+] [-] rvz|5 years ago|reply
Given that the author did a recent article about technical programming interviews, I'd pretty much see this article as enough evidence that the author here knows their stuff in data structures appropriately and also optimising apps beyond his own ones and would bypass the programming interview stage anyway. (All this code is open-source in NetNewsWire).
Great article and nice work on NetNewsWire!
[+] [-] WaltPurvis|5 years ago|reply
[+] [-] abhayb|5 years ago|reply
[+] [-] toast0|5 years ago|reply
I'm not the author, but I've got this facility as well. I guess part one is to have motivation --- it's hard to know what to research before hand[1], but if you've got something that is actively too slow now, that gives you a clear direction. Part two is not being easily satisfied that things are fast enough, or fast as you can get. There's almost always a way to make UI faster, it's just a matter of what needs to break to make it happen, sometimes it's abstraction layers. You can go back in time and look at 1980s UIs and while some were slow, many were super fast, and yet the CPUs were slower than dirt compared to today. We're often marshalling a lot more data and pixels, but it just shows than processing everything in time for the next frame is a reasonable target. Learning to use the profiling tools available is a good concrete first step.
[1] But, don't let that stop you from research into things that are interesting to you, or seem like they might be useful. Knowing something can be done is immensely helpful to doing it, even if you don't remember how it was done.
[+] [-] cpach|5 years ago|reply
[+] [-] ken|5 years ago|reply
[+] [-] developer2|5 years ago|reply
Apple's APIs for macOS and iOS are simply better than those provided by either Microsoft (for Windows), Google (for Android), etc. Apple's APIs are, for the most part, very well-thought-out; their engineers have put together fantastic layers in the operating system and its UI components. The primary reason so many apps perform poorly on Apple platforms is because those apps were developed using 3rd party cross-platform tools (eg. Electron, or making an iOS app with webviews rather than native elements).
Developers who make efficient use of Apple's APIs, and who spend time to reduce their backend response time on remote API calls, will always produce an amazing product. The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage. It's such a breath of fresh air to witness.
[+] [-] ryanwaggoner|5 years ago|reply
Turns out this is a completely rewritten app and the NetNewsWire name went on quite a journey: https://inessential.com/2018/08/31/netnewswire_comes_home
[+] [-] aaronbrethorst|5 years ago|reply
and therein lies the primary reason that I try to never use Core Data if I can avoid it. I almost always want a database. I almost never want to manage a graph of objects. If the backends I spoke to were also organized as object graphs, maybe I’d feel differently about it.
[+] [-] kitotik|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] fouc|5 years ago|reply
[+] [-] gmueckl|5 years ago|reply
[+] [-] RMPR|5 years ago|reply
[+] [-] dewey|5 years ago|reply
[+] [-] tedunangst|5 years ago|reply
[+] [-] chipotle_coyote|5 years ago|reply
> I can't imagine it would be worth optimizing this aspect of the code base.
Well, this is the code path taken when the news reader is starting up or refreshing, right? It feels to me like that's the most important place to optimize an RSS reader, because it has a direct impact on the time between when the user clicks the "Refresh" button and everything is updated. Even if the user doesn't actually need to sit there and do nothing when it's updating, if updating takes 3 seconds instead of 10, it makes the whole experience feel much faster.
[+] [-] acdha|5 years ago|reply
Not critical but definitely noticeable - kind of like how the Atom editor had a bad reputation for input latency even if it was still usable, coloring your perception of the entire app.
[+] [-] edwinyzh|5 years ago|reply
[+] [-] nine_k|5 years ago|reply
If they found out that these operations are responsible for long enough delays, or high enough energy consumption spikes, it would make all the sense to optimize them.
[+] [-] LeoNatan25|5 years ago|reply
[+] [-] BooneJS|5 years ago|reply
NNW is clearly a labor of love for the author who has been involved in macOS development and RSS for a long time. NNW is unabashedly Mac-only and unabashedly fast. I love reading about people's passion projects.
[+] [-] atonse|5 years ago|reply
[+] [-] mikece|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] minimaxir|5 years ago|reply
[+] [-] webwanderings|5 years ago|reply
As much as I would use NNW right away but it isn't really a useful service at this point in time.
[+] [-] baby|5 years ago|reply
[+] [-] stereo|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] manigandham|5 years ago|reply
[+] [-] zapzupnz|5 years ago|reply
Those are my reasons why I'd want a local desktop app, anyway.
[+] [-] setpatchaddress|5 years ago|reply
[+] [-] SllX|5 years ago|reply
This particular iteration of NetNewsWire only shares the name. NetNewsWire 5.0 was originally being developed as Evergreen because Simmons got interested in making another RSS reader. It would never exist as a web app simply because he’s not the type to want it to be anything other than a native app.
Less well known is he was also the original developer of MarsEdit before selling to Daniel Jalkut. MarsEdit to write blogs, NetNewsWire to read them.
[+] [-] dhhwrongagain|5 years ago|reply
[+] [-] jakelazaroff|5 years ago|reply
[+] [-] D13Fd|5 years ago|reply
[+] [-] Hamuko|5 years ago|reply
[+] [-] dirtylowprofile|5 years ago|reply
[+] [-] Wevah|5 years ago|reply