Very interesting article! I was really interested in your pricing experiments!
Thank you!
9 years of Apple text editor solo dev
151–160 of 405 posts
Re: 9 years of Apple text editor solo dev
#152Earlier quoted context omitted.
Yep, I'm also seeing a 2px scrollbar that does not expand.
Oh yes, sorry. This is a form-over-function detail that I added to the website to mimic the app. I did not, however, invest the time to make it expandable. I thought that people anyway don't use the scroll bar that much, and for quick navigation there is the table of contents on the left. I'll see if I can make it more accessible!
> I thought that people anyway don't use the scroll bar that much
It's hard to do when every popular platform seems intent on making it unusable.
Re: 9 years of Apple text editor solo dev
#153Smoothing the caret after character insertion is unbelievably pleasant. Now every other input feels glitchy, almost like continual paper cuts.
What do you mean by "smoothing the caret"? I just tried the app to see if I can make sense of it; do you mean that the caret does not blink if you continuosly insert characters?
Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY
Re: 9 years of Apple text editor solo dev
#154> I had little trust in my ability to pick the right dependencies from an ecosystem that I was not familiar with For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code. This write up is excellent though, some of the gripes I have with the Apple eco system the OP has turned into a 'learnin…
> For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code.
likewise, 80% of the tutorial is preamble to prepare for the 20% you care about.
just don't.
Re: 9 years of Apple text editor solo dev
#155> To my surprise, the Swift one had the full Swift runtime embedded into it — about 5MB, while the Objective-C one was super light — tens or maybe 100KB in total. That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?
That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well. This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
It's been a long time since I did anything in macos/ios land, but in my experience most of the learning curve wasn't in Objective C, which is a fairly straightforward C-like language, but in all the platform APIs. Has Swift changed things much in this regard?
Re: 9 years of Apple text editor solo dev
#156Earlier quoted context omitted.
Scale and niche don't have the same underlying pricing considerations
As if the "minimalist editor" niche isn't already served with 1000 other apps? It's not exactly a niche the author uniquely identified and served. It's one of the most crowded markets when it comes to offerings.
Why don't you let the actual target audience decide whether the niche is served or not? Everyone has a different definition of "minimalist" and niche markets may have more specific requirements, so if someone can sell their specialized tool then what's the problem with that? Nothing of what you wrote is a reason against the existence of more choices.
Re: 9 years of Apple text editor solo dev
#157Lovely writeup. Making that webpage must have taken quite some time also? A question out of curiosity. What are your thoughts on re-writing in Swift? If it were me, I am sure my tech-fingers would itch for a rewrite, but my business hands would slap those thoughts away.
Be real: Apple is not going to rewrite MacOs/iOs in Swift. Objective-C will always be there, offering faster and more robust features. Just look at the Microsoft equivalent: yes, C# is good and all, but the hardcore Windows apps are still using (lightly-skinned) VC++ APIs - after almost 25 years since they started flogging .NET. Swift is for the new rubes, bootcamp graduates and so on.
One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?
Re: 9 years of Apple text editor solo dev
#158> Swift has come a long way and my guess is Apple has either embedded it into their platforms or added some fancy tree shaking for the binary. It went ABI around Swift 5 or so. I took a huge leap of faith, in 2014, and started using Swift, exclusively. It's turned out OK. I'm not quite as positive about SwiftUI, though. I think it will work out, but it has a huge amount of catching up to do, if it is to replace UIKit…
When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive.
The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default way.
All of this greatly reduced my trust in SwiftUI. Seems like they did not have performance in mind in the core design decisions of the framework, and only tested it on small data sizes.
Maybe things have improved since then.
Re: 9 years of Apple text editor solo dev
#159> Swift has come a long way and my guess is Apple has either embedded it into their platforms or added some fancy tree shaking for the binary. It went ABI around Swift 5 or so. I took a huge leap of faith, in 2014, and started using Swift, exclusively. It's turned out OK. I'm not quite as positive about SwiftUI, though. I think it will work out, but it has a huge amount of catching up to do, if it is to replace UIKit…
SwiftUI is pretty good, I've been using to build an app. The big problem is navigation and state handling, it's not intuitive (although I never used AppKit or UIKit so I can't say if it's better or worse)
> The big problem is navigation and state handling
Those seem like very basic features that a UI framework needs to get right.
Re: 9 years of Apple text editor solo dev
#160Earlier quoted context omitted.
Yep, I'm also seeing a 2px scrollbar that does not expand.
Oh yes, sorry. This is a form-over-function detail that I added to the website to mimic the app. I did not, however, invest the time to make it expandable. I thought that people anyway don't use the scroll bar that much, and for quick navigation there is the table of contents on the left. I'll see if I can make it more accessible!
You can't (unless there's a trick I don't know) change the width of the scrollbar when hovering over it. However... you can keep the width constant and have the apparent-width of the scroll thumb be determined by transparent borders.
This would give the appearance of your current 2px scrollbar, but it'd be usable, and would visually expand out to show its grabbable area on hover:
html::-webkit-scrollbar {
width: 8px;
}
html::-webkit-scrollbar-track {
background-color: transparent
}
html::-webkit-scrollbar-thumb {
background: #d73f00;
background-clip: padding-box;
border-left: 6px solid transparent;
}
html::-webkit-scrollbar-thumb:hover {
border: 0;
}
You could also do exactly-this but without the :hover state, and it'd effectively just increase the grabbable-area of the thumb without any visual change to your current style. I like changing the visible width as a form of feedback though. :D