Funny that my story also plus 10 years as a solo app dev is a little different. I shifted from native to full webapps 2 years ago. Never been more happy with that decision. Development speed is a lot higher and easier. I found the iOS SDK, but in particular the Android SDK a monstrosity to work with. Yes there is a very small performance penalty, but for simple list scroll apps not impacting user experience (proof comes from user reviews)
9 years of Apple text editor solo dev
221–230 of 405 posts
Re: 9 years of Apple text editor solo dev
#222I appreciate the technical details, but the only thing that really mattered was the completely arbitrary design decision to make it look like paper, i.e., to adopt a minimalist approach.
This has been the distinguishing feature, as against all the other feature-full applications. Its success has spawned copy-cat's in this and other domains.
The solo dev can avoid following the herd. Developer groups, esp. groups with investors, require mutually-acceptable justifications that reduce to, well, joining the herd.
So as a solo dev, amplify this advantage, and ask: what do people really want, that they can't get from the herd?
(Esp. in an age thundering with AI mash-up's)
Re: 9 years of Apple text editor solo dev
#223Having been developing iOS apps since 2009, hard to believe 15 years, this is one of the finest writeups from a developer I've seen. Congrats on your hard work and the decisions you made developing your app. You made some great decisions, i.e., sticking to native development, no 3rd party dependencies, and sticking with Obj-C. I made the move to Swift when it came out. However, there are many times I miss Obj-C and m…
> I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift.
It would largely look like Swift, since the goals of Swift (and most modern languages), safety and expressiveness, are fundamentally incompatible with C languages. There's really no point to basing a language on Obj-C if you're not keeping 100% compatibility, so they didn't.
Re: 9 years of Apple text editor solo dev
#224Earlier quoted context omitted.
Yeah, you really need to combine SwiftUI with a dedicated architecture like PointFree's Swift Composable Architecture. It solves your state and navigation problems while adding dependency and testing solutions as well. Apple's stubborn and bizarrely proud insistence on not providing the full solution here is very annoying.
just had a look at Composable Architecture, and it looks like swiftUI being the equivalent of react, they faced the same problem and someone developed a redux in swift. Am i correct ?
Kind of, but without the reactive UI bits, since SwiftUI already provides that (they provide a way to publish state into the older frameworks as well). It's heavily inspired by Elm and React but doesn't match 1:1 with either.
Re: 9 years of Apple text editor solo dev
#225I appreciate the technical details, but the only thing that really mattered was the completely arbitrary design decision to make it look like paper, i.e., to adopt a minimalist approach. This has been the distinguishing feature, as against all the other feature-full applications. Its success has spawned copy-cat's in this and other domains. The solo dev can avoid following the herd. Developer groups, esp. groups with…
[deleted]
Re: 9 years of Apple text editor solo dev
#226First of all this is amazing. Amazing app, amazing dev, amazing story. Everything that the hacker culture stands for, is flourishing in your app. My question is do you make enough to live off apps like these? I really hope so, because these are some of the best tech products in the world and I would love to see more of these.
Thank you!
Sadly, not enough to live off it in Europe.
But it's slowly growing, so maybe one day. :)
Re: 9 years of Apple text editor solo dev
#227Earlier quoted context omitted.
One problem in the past was -[NSArray firstObject], which many developers used as a category method, with differing implementations. Apple added it to the Mac OS X 10.9 SDK but actually implemented the method silently in 10.6!
Interestingly it seems to be 10.6+ in the documentation. They backdeploy like that sometimes I guess.
Read the real documentation, the archive. ;-) https://developer.apple.com/library/archive/releasenotes/Fou...
Re: 9 years of Apple text editor solo dev
#228Since the author seems to be in the comments, have you ever considered implementing a Typora-style live preview? (Typora, for those who don't know, hides the Markdown formatting as you type, and shows it again when you move the cursor back onto the text.) Paper appears to have a more traditional split between text mode and preview mode, and you can't properly edit the formatting in preview mode (e.g., you cannot turn…
That would be a massive challenge and probably would lead to more bugs which is against my goal of having a low-maintenance product. The more dynamic is your text rendering, the harder it gets. You can format from the Preview mode, by the way. You need to use the shortcuts for that or click inside the Format menu. If you put your caret on the line of the heading, then press Command+1/2/3 depending on the level of the…
Fair enough. Thanks for the response!
Re: 9 years of Apple text editor solo dev
#229> For instance, the NSPopover is a good candidate for bubbles that hint at stuff in the Mac app. An iOS counterpart sadly does not exist, so no bubbles in the iOS app. Ignoring popover presentations in UIKit, there’s also a new TipKit framework in iOS 17, but it’s Swift-only. https://developer.apple.com/documentation/TipKit The author has done a great job while remaining in Obj-C. I’m really curious how long they can…
Thanks! Indeed, there is TipKit. I've just learned about it a few days ago. I think so far when Apple added new features to existing components, they've always made dual APIs. Only some completely new things are Swift-exclusive. That said, as the pile of those exclusive things gets bigger, it would be harder and harder to stay in Objective-C.
You know you don't have to choose one or the other, right? The languages interoperate and there's really no overhead to adopting Swift anymore. On newer OSes you're using tons of Swift under the hood anyway.
Re: 9 years of Apple text editor solo dev
#230I cannot have read that correct. For people on the Apple Dev ecosystem, do you really have no access to SDK code as a reference? Not even some high level abstraction version? I got to that assembly code part and just sat there and re-read it again and again. "You've got to go straight to assembly mode?" I cannot have read that correct.
You might want to clarify your question:
> do you really have no access to SDK code as a reference?
You get headers but no source. While Darwin is in theory open source, UIKit, et. al. are not.
> I got to that assembly code part and just sat there and re-read it again and again.
If you're referring to the screenshot, Xcode dumps you into disassembly in cases where the stack is not in your code. 0 -[MoTextView endFloatingCursor] is the author's code. The remainder is UIKit. Also, most of the line items are _prefixed which indicates a private method upon whose existence (much less implementation) is not reliable. As the author mentions, the stack on the left is usually enough to diagnose problems.
It's also one more thing that makes me fight using Swift; all of the name-mangling and opaque to the Objective C runtime additions make this problem even harder.