> Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser.
Huh, that sounds contrary to what people usually tout as a benefit of native. You always hear about framework churn and cross-platform problems when it comes to JavaScript. Maybe that’s not so true anymore?
Also goes in the other way. We can literally only support iOS 17 because we’re using SwiftUI and Apple refuses to backport anything, whereas in JavaScript you can generally use new APIs while either gracefully failing or triggering a fallback
Just don't use frameworks, or use the stable ones.
I use React and it had exactly one significant major change (class components -> functions & hooks) since 10 years ago when I started out with the beta release.
Windows went through 4 different "recommended" GUI frameworks and many more major API changes during that time.
Native on other systems, perhaps. But for MacOS it's common that half your apps will break if you update as soon as the update is available. Got to give each developer time to fix their app first..
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?
When you type a character, the cursor smoothly animates from its previous position to the new one. As opposed to most apps where the cursor instantly jumps one character width to the right.
> 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.
Have you ever developed anything substantial with Objective C? If not, I suggest that 'unfamiliar' might be more apt than 'archaic'. Anyone starting a non-trivial iOS project in 2015 in Swift would still need to learn the basics of Objective C because so much of the documentation and examples were still in Objective C at that time. I don't think it's accurate to say that learning Objective C in 2015 had no benefits.
> 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.
Some benefits:
1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.
2) Swift compile times are still vastly slower than Objective-C.
3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).
Yup; 2015 was not the right time to move to Swift for most people.
If I started a new app today, I'd use Swift -- it's mature enough. But in 2015 and for a long time after, it wasn't really a good option unless you wanted to be on the bleeding edge (and you were willing to bleed).
Compile times will always be slower than Objective-C, but the compiled code _can_ be faster, with effort. And maybe someone will eventually break down and write a Swift-centric debugger.
I think even today Objective-C has some unique benefits for me. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.
Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)
Aside from inline assembly, Swift can operate at just a low level, it just requires more work, since those operations are unsafe. All of Apple's public frameworks are importable into Swift. At this point there are more frameworks unavailable in Obj-C.
Depends what they are. Most of the time those are unavailable because they've been replaced with better Swift imports of the same API somewhere. Less commonly it's because they use one of the few C features that can't be imported into Swift or, even more rarely, because the API is fundamentally unsafe and they don't want it available in Swift. In all cases you can reexpose these APIs to Swift by writing your own C wrapper.
>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 easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).
> The author forced himself to learn archaic Objective C for a completely unnecessary reason
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
And yet here they are, with a great app, some amount of sustained revenue, and a front page post on HN. Is that an accident?
The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.
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?
What should something like Photoshop with 10000x the features and development costs then charge? $1000/month?
I understand "keeping it simple" but not "keeping it simple AND charging a crazy price for it" (there are essential, complex apps, that charge much less than that).
>If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
My more general objection to your question is that I don't consider individual preference, or individual choice, or individual action beyond criticism, just because the individual is "fine with it".
People can "find a product, like what they see, and be willing to pay the price", and the purchase could still be stupid and deserved to be called as such, and the price could still be highway robbery and be deserved to be called as such, and the product could still be subpar/average/bad and be deserved to be called as such.
Do you think you know better than the companies developing these products and the consumers buying them? Do you believe you understand what the right products and fair prices should be? This seems to justify your use of terms like 'highway robbery' and calling people 'stupid'.
I would have words for such viewpoints, but for the sake of a civilized conversation, I won't express them here.
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.
Why should the author care whether their price scales to Photoshop level?
Price should scale with demand. A company like Adobe might want to maximise revenue, so they price it optimally to make the most money out of their product.
A single developer might not want to support half a billion users at $5. If selling at $60 means a lower number of users and a manageable number of support requests per month, it is a much better idea, even if it means less revenue. And in general, at higher prices you get better quality customers.
Pricing is hard, because it is not intuitive. And more importantly, the value of something is often subjective. People tend to forget that.
No one is getting scammed here, even if it cost 1000x as much. Why are you saying buyers don't know what they are charged?
> stupid personal buying decisions
Why does it affect you so much what other people are doing with their money? Spoiler alert: it is none of your business, and you are taking it way too personal.
>No one is getting scammed here, even if it cost 1000x as much. Why are you saying buyers don't know what they are charged?
I'm obviously not saying they are blindly charged an amount that they don't know.
I'm saying that they are buying stuff influenced by the minimalist fashion/emotion/etc and they don't know they're overpaying for no good reason.
>Why does it affect you so much what other people are doing with their money?
Because I live in a society, not in the wilderness. What people do with their money affects everybody, and people making better decisions is good for society in general.
>Spoiler alert: it is none of your business, and you are taking it way too personal.
While answering to me is "your business"? And getting into direct personal comments (as opposed to making a general remark)?
Long ago I paid somewhere between $25 and $100 for a calculator construction kit on Mac classic. Purely a purchase of love because it seemed like cool software and I love RPN calculators.
I resent the modern attitude that paying for software is an undue burden.
>Historical note: Photoshop cost $895 in 1990, which is more than $2,100 today.
I know. I've used it for decades.
But $2100 for Photoshop - a professional working tool - even today, is way more justified than $100 for a "minimalist text editor" (or $120/year subscription for same). Not to mention you can get Photoshop+Lightroom+1TB storage for the same exact yearly subscription price.
If it wasn't a piece of software but something like a barebones plastic spatula sold for $100, people would just laugh it off. But because it's software and intangible we can mystify the end product and pretend like there aren't some much more realistic prices one would expect it to be sold at, and it's "all about demand". In other words, we bring in some of the mystification from the fashion industry, where the same t-shirt (materials, labour, design, etc wise) costs $10 in some outlet and $200 in another because it has a different brand name attached to it.
You're making a common pricing mistake: the price of a product has absolutely nothing to do with the cost of building it. Nothing. Price only depends on what people are willing to pay for it, i.e. on the perceived value.
Just because you aren't the target audience for such a product doesn't mean that audience doesn't exist. The world is large.
Personally I see a great business in premium tools for the elites in any domain. A professional writer probably wouldn't mind shelling out an extra $1000 a year or more for a premium tool that's better than anything else out there. Smaller audience, but it likely exists.
This goes both ways: if people aren't willing to pay even the price it takes to make the product, you go out of business. This happens often as well.
If photoshop saw an opportunity to increase the price to generate greater revenue, of course they'll try to do so. These changes in pricing and priorities often lead to opportunities for new products & companies.
I wish more software companies would take the approach of not bloating up everything and constantly updating everything. Its like the keeping up with the Joneses mentality but for software.
I created an account on this site (after years of lurking) just to upvote you here.
Just because other people are willing to spend this kind of money on a text editor doesn't mean we can't think they are ridiculous for doing so. I definitely judge people who spend $10 on a text editor.
The website barely gets any traffic. Almost everyone downloads directly from the App Store. The prices are visible there. Plus they fluctuate per country, so showing only the US prices is also misleading.
Have you checked the App? It's a very specific experience, nothing like you'll see on other apps. Someone put a lot of thought on it and polished it thoroughly. The app feels like a design piece, where someone had opinions on how things should be done and made it.
If you like and want that, you pay. If you don't you ignore.
Personally, I like it very much. I always enjoy seeing something well thought that would not necessarily fit everyones needs. Did I bought it? Not now because I don't see myself writing lots of text but if I had been writing I would definitely consider id because I want it despite not needing it ATM.
Let's put it like this: you want a nice drawer to store clothes. It has one purpose and one purpose only. You can either go to Ikea and get a 50 EUR drawer that will do the job, or you can pay 500 EUR to a local artisan for a nice cabinet with solid wood, an elegant design, a nice finish and even good wood for the back part. Literally depends on who you are, but I don't see how this is any different.
And before "software is cheap and wood is not", yes, but paint is also cheap and you don't judge an art piece by the price of the materials used.
Is software cheap? Even a small project can a few weeks to hack things together, and if you try to price it based on your hourly salary, the cost can climb in the thousands really fast.
Plenty of people, it turns out. I spend ~7 hours a day using a text editor, I don’t mind paying for a good one if it makes that a bit more pleasant or enjoyable. I think my barrier for impulse buying software like this is around €100.
The other week I just purchased a Hacker News app on iOS from a solo dev, for support. As an iOS developer myself it is vital that we support each other. I am not even rich.
Nice write-up, it's been a while since I started a project in Storyboard. I am not yet done reading but I'm curious why there is no mention of [0]AutoLayout.
It's been a hot minute since I've done work in this ecosystem, but I am not sure it is accurate to say that Storyboards do not support Auto Layout. I used to build iOS apps with Storyboards and Auto Layout a few years ago.
Looks nice and kudos for sticking with Objective-C. Still a nice language which compiles quickly (well, any language compiles quickly compared to Swift).
The visuals and attention to detail reminded me of Bvckup (https://bvckup2.com).
Downloaded the app to check the "smooth caret" somebody mentioned, started typing and got interrupted after 3 words by a popup telling me to check out PRO features. Oh well. Next, a OS popup about notifications... no thanks. I don't expect any notifications from a text editor. Or at least give me a minute to check it out on my own.
I should delay asking about notifications as well. It's for the support chat that I mentioned in the article. If I write back in that chat, I fire a local notification. Makes sense more sense to ask for that permission only when the user has written something to the chat.
Hi, it’s very beautiful app and very nice write-up. I am a solo developer too with attitude to the quality of apps very similar to yours and in my case it is a file manager for Mac OS. The file manager is written in objective-c as well and was gradually developed for some years already. It is very lightweight and I am using it daily as working horse to test and monitor it’s quality. It is at polishing stage now and when I am thinking about certain integration with text editor I believe it should be nothing less than something like you’ve made. Your attention to details and quality of user experience is facilitating and very resonate with with my approach to my app. I was not thinking about something particular at the moment but I thought may be there is an opportunity for us to cooperate in some form at some point and be generally in touch perhaps.
All the "fringes" stuff is where the magic is. The author suggests that no one notices some of the refinements, well this may be true on day one, but people discover these touches as they grow more familiar. Those subtle thoughtful additions are what makes the difference between an app I like using, and one I love using. They help me feel a couple of things:
1) A connection; I feel like I noticed something just for those who care
2) Assurance the product is well cared for
3) A feeling that the dev understands me
This stuff is gold for a product. I am thinking of Procreate when I think of the king of this sort of thing. That app is just so ridiculously clever. I don't know how they managed to take the plethora of UI that other illustration apps have and squeeze it down into ~6 menu items. Somehow it works beautifully and there are so many subtle touches and hidden workflow gestures just waiting to be discovered. It's usable out of the box, and the more you use it the more you naturally learn how to use it more efficiently.
I love many things about Procreate, but their palm rejection is terrible (ie inexistent) compared to every other drawing app which means the canvas often zooms/rotates wildly while I’m drawing (maybe cause I’m left handed?), making it super frustrating to use; they’ve ignored requests to address it with eg canvas lock for years ;_;
I have had no problems with this, but I use an iPad Mini for all my sketching and my palm is often off of the screen to the side as it's a small surface.
This is very true, and with regard to product success, the opposite effect here is a sad story - a tool full on lots of small annoyances is death by a thousand cut because each is hard to describe it doesn't seem worth explaining and so you get no telemetry for why nobody uses your product.
Not to steal your thunder about a MacOS-specific text editor, I would say that many Windows devs would say the same about Notepad++ and Sublime Text. While I am not a Windows fanboi, when I am forced to use that platform, I am always searching the Start Menu to run those text editors! I agree: The "TLC" (tender, loving, care) is well transmitted to users over the long run. The endless number of "hacker-friendly" features slowly builds a rabid fanbase.
It depends on what kind of app you are making. Text editor is probably where the "craftsmanship" shines the most, cause there are just way too many text editors out there.
(Un)fortunately in many other cases it doesn't work like that. People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily, because the only alternative is get it over the counter in person.
> People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily
It's worth questioning why this is, as often as you can. We have a wallet app / payment system on most mobile devices that is card agnostic and gets better interfaces. Meanwhile, other services have to make do until a big player like Amazon or Ticketmaster comes along, consolidates the industry and starts charging high rents.
Apple has a lot of niceties like this in their software. I've had so many times I thought "I wonder if I can do this?" and it just works because a designer thought of it before me.
Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last in queue. Usually if I want it somewhere specific in the queue, I'd just add it next and then move the song where I wanted it, but if I'm adding an album partway through the queue, that means you'll be dragging a bunch of tracks manually. So I thought, "it'd be nice if I could just drag things exactly where I want in the queue and drop it there." And then I figured I'd actually try it. If you press and hold a song/album and yank it from its place, it stays under your thumb. You can then either operate with another finger to open up the queue, or hold your thumb over it to pop it open, and then just drop it exactly where you want in the queue.
Not the first time I've come across something like this, but it's the kind of thing I only find on Apple platforms, particularly with their own apps. As much as I liked Google Play Music, you couldn't do it there, and I just checked Spotify and it doesn't let you do that either.
I'm surprised to see an example from Apple Music. That app is an perfect example of design neglect too. The ability to filter your song list for a specific track is now hidden in Apple Music.
To reveal the filter field, you must select the "View" menu, and "Show Filter Field". Worse each time you relaunch Music, this field is again hidden, and you have to select the menu item again.
It's much worse for apple music classical. It's great for classical music, but the way the library works with works and recordings is unintuitive and they decided to remove the ability to download (!?) and the ability to share playlists in the classical app and those as main-app only.
> people discover these touches as they grow more familiar
people discover these touches in the breech, when they need to move on for some reason or other, and all that's familiar is lost. in the words of Joni Mitchell, "you don't know what you've got till it's gone"
Out of curiosity is that a hand crafted page? It is a nice flow with the animations and the graphic call-outs, etc. I'm personally not interested in the Obj-C code snippets but that overall layout of the page, the sidebar ToC, the minimalist design is just really stunning.
Also - how did you do the visuals in the "Gnarly Bits" section that split the page/components out into verticals? That is such an amazing way to display the internals of a thing like a page.
If these elements could be packaged into a blog theme for whatever blog hosting platforms are popular these days I bet you'd get a bunch of people to purchase. Nice work!
It's hand-crafted with TailwindCSS, vanilla HTML, and JS. I've worked on it for 2 months part-time. I was hoping it would get people's attention, and so it did. :)
The component split is done by hand in Figma with regular screenshots and cropping. I also used a plugin for skewing.
I think it's still annoying. When reading, I often look at where the scrollbar is to get an idea of how much reading is left. Right now, the scrollbar is so thin that I have to waste time looking for it. On a 34" monitor, it's very annoying.
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.
They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.
Disclaimer: I work for Microsoft, though I wasn't there during the early days of .NET or Windows Longhorn.
C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code.
Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues.
The difference is really about what the stated goals of the language were/are.
Thank you to share. My guess: In the year 2000, it was impossible with current desktop computing power to use C# for OS internals. In 2024, it is a different story.
That's what MS said as well, when they were pushing C#. All Windows will be using safe code! Still waiting... Another example is Mozilla and Rust - hell, I wouldn't be surprised if there was still Netscape code somewhere in the bowels of FF/TB!
Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
> That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple).
It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong.
My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
> Your point about Foundation was meaningless and the others just nits. Do you have an actual point to make?
My point, as always, is the truth. You said two false things, which you subsequently admitted were hyperbole. Truth is valuable in itself, and more important than "points", i.e., arguments or motives.
If I were to make a point, though, it's that Objective-C still has a very long life ahead of it, and its complete replacement, if that ever occurs, will be an arduous process, given the amount of extant Objective-C code in the operating systems and first-party apps (not to mention third-party apps). It's not just Objective-C either: C++ is also used quite a bit in the OS. Think of WebKit, for example.
You're not going to be able to hire many people with Objective-C experience nowadays. Engineers with 7 years of experience just writing iOS apps will very likely will have only used Swift in their work experience. I work with 2 of them now.
The article author is a solo indie dev. I'm a solo indie dev. We don't need to hire.
By the way, we could be hired, for the right compensation. Nonetheless, companies almost never try to recruit me, but they still whine about how "hard" it is to find ObjC developers. They're not even looking.
Besides, experienced engineers can learn a new programming language. Do you think that every engineer Apple hired before 2014 had Objective-C experience?
This is turning into a silly argument… but anyway there's a blogger who has been tracking the number of binaries written in the various languages (and appkit vs catalyst vs swiftui etc.) for years.
Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago).
At this point you can't separate Swift from the rest of the system so cleanly. Since it's now included with the OS directly and linked to from many system libraries, including parts of Foundation which have been directly rewritten in Swift while maintaining ABI compatibility with Obj-C callers, virtually everything on the system that uses Apple's frameworks uses Swift to some degree.
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?
When I switch between C or C++ and a (non-deterministic) VM-based language like Java or C#, it feels like 10x. The IDEs are way more advanced, including (for me) the #1 all-important: debugging. For me (a mere mortal, average programmer), the fact that null pointer exceptions are clear in Java/C# is a huge gain compared "core dump" in C or C++. Going further, I am sure many would say the same kind of productivity speed-up for C or C++ to Python or Ruby.
I have a bit of code I use for ARM Cortex devices where I can trap bus errors. Most of the time I can recover the program counter where that happened. And use addr2line to get the file and line number. I've heard game developers talk about doing that sort of thing as well.
I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043'
In C++ I'm dubious you couldn't throw an exception instead of dumping.
[1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.
Apple does use Swift in their IDE, Xcode. Several years ago they rewrote the text editor component in Swift. It’s taken them a while to get all the features back that the old one had, and has had a fair amount of bugs as well. I often wonder why they didn’t just leave it in ObjC and add the new features they wanted to add, like the minimap or sticky declaration heaters.
I definitely wouldn’t call Swift a 10x improvement in efficiency, and I like coding in Swift. I do advent of code in it each year, but spend a fair amount of time just fighting with the compiler–after all these years, it still emits strange or just flat out incorrect diagnostics.
I concur. I'm 10k LOC deep into a SwiftUI app (Absolutely no clue how much that works out to be in Objective C + UIKit equivalent code), and one of the most frustrating things (after all the stuff you can't do without a PhD in apple internals) is how piss poor Swift errors are. I've changed a line of code in one file, and then another, completely unrelated one stopped compiling. Most frequently, it's something about how checking the file took too long and it should be broken up (which you will learn, really means you have a small error somewhere in said file and swift isn't in a sharing mood)
Just downloaded this app. It's not often you see indie apps that are this well designed. It almost feels like you're using something that is hand coded in Assembly - so fast!
The author did say he experimented up and down with prices and what people would pay for. If people think they are getting more then 33 cents a day worth of productivity out of the app ... then it works for them. Does seem rather high to me as well.
Enjoyed even the transparency on pricing thinking, but one price that doesn't seem to have been experimented with is allowing a one time purchase that is not an in-app purchase.
In-app purchases make your app unavailable to company employees where the company manages the Apple device using MDM and purchases software using e.g. Apple Business Manager or the older volume purchasing. The $99 option should also exist as a standalone retail version so a company can buy the app for employees.
For small app makers: you might be surprised that a company-managed Mac with a company managed AppleID cannot use in-app purchases. Apple has no way for a company to do IAP for an employee, and in fact the employee cannot do it themselves either. For such users, you must either (a) allow retail app purchase, or (b) have an out-of-band subscription purchase and management, like Microsoft M365 or Adobe Creative Suite.
Whether you do it out of band or as a one time retail purchase, if you do track logins, you should support the simple "Login with" or "Continue with" buttons for Microsoft to hit the 85% of small businesses with identities on that platform, but also Apple and Google. These buttons are easier to add than devs might think. You don't need "SSO" to let most companies log in with company IDs.
I've always avoided non-App Store distribution to keep things simpler. It's a nightmare to manage many different licensing schemes.
Now I don't have to have any backend. Everything is done via the built-in, robust App Store mechanism that just works.
I hope Apple will figure something out in the future. And I think they will since they want to increase their "Services" revenue as hardware sales decline. Making stuff easier for business customers seems like a low-hanging fruit.
It's not confusing. They show up next to each other when you search. One is "free" showing "GET" and offering usually ad supported + IAP. The other is paid, with a special logo, saying life time purchase, no ads, or etc. You can link to each other and talk about the other.
I'm not at work so I can't readily pull up a list of the apps we can and do buy employees thanks to having a paid version available, but there are quite a few, and they win out over more popular apps that have only IAP.
I think the regular, unsophisticated user might still be confused. I already envision questions like: "Should I buy a lifetime license in the free version or the paid pro app?". There are also additional hurdles like, for example, reviews being divided between 2 separate apps. I don't know, maybe it's worth it, but I am hesitant. I want to keep the whole experience of Paper simple, and this just adds complexity. I would prefer to wait for Apple to solve this at some point in the future.
I honestly thought that the scrollbar didn't work at all until I read this comment. If I put the site on my right monitor, I can grab the scrollbar by just going to the edge. But on my left monitor, where I typically have the browser, it's almost impossible.
I too find it very annoying, especially for such a long article.
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.
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:
(The key to it is the background-clip property, that lets you use the border to control where the background is drawn.)
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
Fantastic writeup (read all the way to the end!), and especially impressed the author is brave enough to include a chat support tool. I'd be worried that somebody would lean on the Z key for 20GB and constantly spam my chat.
I have a copy of IA Writer that I've somehow never used, so maybe I'll buy this to add to the pile.
> Categories in Objective-C are a way to add new methods to any existing class, including framework classes (categories can also be used to replace methods, which is both powerful and scary ). I use them to harmonize the API. So if a method in UITextField is called text and in NSTextField it is called stringValue I can add a stringValue method to UITextField that calls text (or vice versa).
> By the way, I also use categories to shorten long framework methods. The underscore at the end helps to avoid clashes with public or private methods that Apple might decide to add in the future.
I think you already know what will happen if Apple adds a method (public or private) called text to NSTextField or stringValue to UITextField in the future ;)
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!
> 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/AppKit.
I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
I've released a SwiftUI app, but was a nightmarish experience. They are experimenting and changing stuff to better serve SwiftUI philosophy, like the change from Combine to Observation. There were plenty of bugs and some of them difficult to debug like previewing screens on Xcode, sometimes it keeps crashing. When it works it's marvelous. I hope they can stabilize it.
You can still use Combine in Swift, but I agree Observation in general feels inferior for all but the most mundane cases.
It's like you go through a SwiftUI tutorial placing @Published and @ObservedObject everywhere, and then once you're writing the app you realize what you need is Combine except you haven't learned that yet
I follow the development of Swiftcord, A SwiftUI Discord client, on the developer's discord, and they almost constantly lambast how much is apparently missing or unstable between AppKit and the current version of SwiftUI, which has made it a struggle to get to feature parity with the official Discord client based on Electron cause lots of things you expect either have to be implemented by hand or just can't be done IIRC.
> I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
Looking inside the BBEdit app, I see some Swift in BBEdit.app/Contents/Frameworks/CandiedYams.framework, which appears to be a third-party framework (CFBundleIdentifier org.darkrainfall.candied-yams), but not much else.
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)
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.
Apple seems to think the UI frameworks should only focus on UI, and so overall arch is an afterthought. You can, of course, navigate and store state using the tools provided, but it's a pain to do so beyond local screens, where you have to manually pass things around, and you lose most testability.
You should give it an other go building on SwiftData and the new Observation API’s. They made leaps and bounds and it’s so much better now!
I’m having a lot of fun with it at the moment. If you stay within the bounds of how they encourage you to build the apps, you can just go go go and with very little work release a fast, stable, native app across all their platforms.
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.
No, List still has some awful performance cliffs unless you go out of your way to model your infinite lists in a way it can handle. There are some nice UI / NSTableView / CollectionView wrappers nowadays though.
The great strength of SwiftUI is that until they have caught up with UIKit and AppKit you can just drop down to those frameworks. So you can use SwiftUI in 95% of your app and where you run into limitions you can use the lowerlevel NSCollectionView for example. Whats even cooler is that inside that NSCollectionView you can just use SwiftUI views again.
That has some unique edge cases as we have been discovering when you interleave UIKit and SwiftUI together.
I kind of wish that SwiftUI was a clean break in some ways and did not depend on UIKit and avoid all the abstraction leak issues that have been arising as a result. I know that would never happen in practicality although.
I wish Apple had stuck to Model-View-Controller instead of shoehorning React philosophy into their native UI framework. Personally, I find the "old-school" way of doing things far easier to follow and understand.
React is popular for a reason. Declarative UI is a million times easier to implement and maintain. If a total newbie had to learn UIKit and SwiftUI then pick one, they'd pick SwiftUI 100% of the time.
I always make it a point to buy small apps that are well-designed, well-engineered and well-architected in order to support the developers who make them.
> In the end, building a polished, frictionless support chat was one of the best decisions that I have ever made for Paper.
Many many years ago, I used to run a web hosting company. One of the first things I did was I built one of those little chat widgets that let me chat directly with visitors on my website. This was around the year 2000 and before I had ever heard of liveperson which was somewhat new at the time. That single feature did more for my business than anything I did. Because I could talk directly with customers (and potential customers), and because I was the sole decision maker for the business, I was able to say yes to ridiculously obscure requests for features that were easy to implement but very valuable to just one specific customer. My hosting business never grew into a large company but it did support me through college and for a while afterwards.
I did have a phone number, however, when someone is about to click "buy" on a website but they have one hesitation, they aren't as likely to dial a phone to get an answer. When they can click a button and have instant response right there on the page.
> 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 'learning' experience in a positive way. Really nice.
> 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.
"Here is the compacted multi-line command I used to set up an environment a few years ago. I will not be explaining what it does or why you need these specific lib versions, but will assume that we all have a few of their dependencies installed."
And it's still the most useful guide to setting up Qt because it's the only first-page result that mentions Berkeley.
404 comments
[ 2.5 ms ] story [ 303 ms ] threadHuh, that sounds contrary to what people usually tout as a benefit of native. You always hear about framework churn and cross-platform problems when it comes to JavaScript. Maybe that’s not so true anymore?
I use React and it had exactly one significant major change (class components -> functions & hooks) since 10 years ago when I started out with the beta release.
Windows went through 4 different "recommended" GUI frameworks and many more major API changes during that time.
That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?
https://www.swift.org/blog/abi-stability-and-more/
https://news.ycombinator.com/item?id=38651690
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.
Some benefits:
1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.
2) Swift compile times are still vastly slower than Objective-C.
3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).
If I started a new app today, I'd use Swift -- it's mature enough. But in 2015 and for a long time after, it wasn't really a good option unless you wanted to be on the bleeding edge (and you were willing to bleed).
Compile times will always be slower than Objective-C, but the compiled code _can_ be faster, with effort. And maybe someone will eventually break down and write a Swift-centric debugger.
Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)
So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?
It's easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).
Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product.
Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.
Swift is lighter on the eyes, but it still uses the same APIs when paired with UIKit/AppKit.
SwiftUI is a different thing though. It's like React for UIKit/AppKit and has a different API.
What should something like Photoshop with 10000x the features and development costs then charge? $1000/month?
I understand "keeping it simple" but not "keeping it simple AND charging a crazy price for it" (there are essential, complex apps, that charge much less than that).
I guess, if you can get away with it...
It's one of the most crowded markets when it comes to offerings.
If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
My more general objection to your question is that I don't consider individual preference, or individual choice, or individual action beyond criticism, just because the individual is "fine with it".
People can "find a product, like what they see, and be willing to pay the price", and the purchase could still be stupid and deserved to be called as such, and the price could still be highway robbery and be deserved to be called as such, and the product could still be subpar/average/bad and be deserved to be called as such.
I would have words for such viewpoints, but for the sake of a civilized conversation, I won't express them here.
Yes.
Do you think it's impossible for someone else to know better than the buyer if the latter got a good deal for a product at a given price?
If so, I have a bridge to sell you.
>I would have words for such viewpoints, but for the sake of a civilized conversation, I won't express them here.
Good for you. I have similar words for your viewpoint.
I do. Do you see me passing any laws or enforcing something to prevent it?
Am I allowed to criticize their decision though, or is that to much to ask?
>Nothing of what you wrote is a reason against the existence of more choices.
That's because writing against "the existence of more choices" wasn't my point. It was about criticizing stupid choices.
Price should scale with demand. A company like Adobe might want to maximise revenue, so they price it optimally to make the most money out of their product.
A single developer might not want to support half a billion users at $5. If selling at $60 means a lower number of users and a manageable number of support requests per month, it is a much better idea, even if it means less revenue. And in general, at higher prices you get better quality customers.
Pricing is hard, because it is not intuitive. And more importantly, the value of something is often subjective. People tend to forget that.
The author shouldn't. Buyers should care what they're charged.
>Pricing is hard, because it is not intuitive. And more importantly, the value of something is often subjective. People tend to forget that.
And subjectivity often leads to stupid personal buying decisions. People tend to forget that.
> stupid personal buying decisions
Why does it affect you so much what other people are doing with their money? Spoiler alert: it is none of your business, and you are taking it way too personal.
I'm obviously not saying they are blindly charged an amount that they don't know.
I'm saying that they are buying stuff influenced by the minimalist fashion/emotion/etc and they don't know they're overpaying for no good reason.
>Why does it affect you so much what other people are doing with their money?
Because I live in a society, not in the wilderness. What people do with their money affects everybody, and people making better decisions is good for society in general.
>Spoiler alert: it is none of your business, and you are taking it way too personal.
While answering to me is "your business"? And getting into direct personal comments (as opposed to making a general remark)?
I resent the modern attitude that paying for software is an undue burden.
I know. I've used it for decades.
But $2100 for Photoshop - a professional working tool - even today, is way more justified than $100 for a "minimalist text editor" (or $120/year subscription for same). Not to mention you can get Photoshop+Lightroom+1TB storage for the same exact yearly subscription price.
If it wasn't a piece of software but something like a barebones plastic spatula sold for $100, people would just laugh it off. But because it's software and intangible we can mystify the end product and pretend like there aren't some much more realistic prices one would expect it to be sold at, and it's "all about demand". In other words, we bring in some of the mystification from the fashion industry, where the same t-shirt (materials, labour, design, etc wise) costs $10 in some outlet and $200 in another because it has a different brand name attached to it.
Just because you aren't the target audience for such a product doesn't mean that audience doesn't exist. The world is large.
Personally I see a great business in premium tools for the elites in any domain. A professional writer probably wouldn't mind shelling out an extra $1000 a year or more for a premium tool that's better than anything else out there. Smaller audience, but it likely exists.
This goes both ways: if people aren't willing to pay even the price it takes to make the product, you go out of business. This happens often as well.
If photoshop saw an opportunity to increase the price to generate greater revenue, of course they'll try to do so. These changes in pricing and priorities often lead to opportunities for new products & companies.
Just because other people are willing to spend this kind of money on a text editor doesn't mean we can't think they are ridiculous for doing so. I definitely judge people who spend $10 on a text editor.
I'm not passing some law preventing people buying a barebones text editor $100 (or $10/month). Just criticizing the wisdom of that decision.
This is false. The prices are listed in the App Store.
If you like and want that, you pay. If you don't you ignore.
Personally, I like it very much. I always enjoy seeing something well thought that would not necessarily fit everyones needs. Did I bought it? Not now because I don't see myself writing lots of text but if I had been writing I would definitely consider id because I want it despite not needing it ATM.
I have not personally bought it, but I've wasted 60 on way more useless things.
And before "software is cheap and wood is not", yes, but paint is also cheap and you don't judge an art piece by the price of the materials used.
[0]https://developer.apple.com/library/archive/documentation/Us...
https://developer.apple.com/library/archive/documentation/Us...
The visuals and attention to detail reminded me of Bvckup (https://bvckup2.com).
Downloaded the app to check the "smooth caret" somebody mentioned, started typing and got interrupted after 3 words by a popup telling me to check out PRO features. Oh well. Next, a OS popup about notifications... no thanks. I don't expect any notifications from a text editor. Or at least give me a minute to check it out on my own.
No thanks...
I'll think about delaying that popup. :)
I should delay asking about notifications as well. It's for the support chat that I mentioned in the article. If I write back in that chat, I fire a local notification. Makes sense more sense to ask for that permission only when the user has written something to the chat.
But in this case I feel that paper was crafted with a strong vision and care. So you could say that you can _tell_ this was made with love.
1) A connection; I feel like I noticed something just for those who care 2) Assurance the product is well cared for 3) A feeling that the dev understands me
This stuff is gold for a product. I am thinking of Procreate when I think of the king of this sort of thing. That app is just so ridiculously clever. I don't know how they managed to take the plethora of UI that other illustration apps have and squeeze it down into ~6 menu items. Somehow it works beautifully and there are so many subtle touches and hidden workflow gestures just waiting to be discovered. It's usable out of the box, and the more you use it the more you naturally learn how to use it more efficiently.
https://folio.procreate.com/discussions/3/6/13198
https://folio.procreate.com/discussions/3/6/13105
Shouldn't that be pretty easy to implement, too? Just a button that prevents rotation...
(Un)fortunately in many other cases it doesn't work like that. People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily, because the only alternative is get it over the counter in person.
It's worth questioning why this is, as often as you can. We have a wallet app / payment system on most mobile devices that is card agnostic and gets better interfaces. Meanwhile, other services have to make do until a big player like Amazon or Ticketmaster comes along, consolidates the industry and starts charging high rents.
Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last in queue. Usually if I want it somewhere specific in the queue, I'd just add it next and then move the song where I wanted it, but if I'm adding an album partway through the queue, that means you'll be dragging a bunch of tracks manually. So I thought, "it'd be nice if I could just drag things exactly where I want in the queue and drop it there." And then I figured I'd actually try it. If you press and hold a song/album and yank it from its place, it stays under your thumb. You can then either operate with another finger to open up the queue, or hold your thumb over it to pop it open, and then just drop it exactly where you want in the queue.
Not the first time I've come across something like this, but it's the kind of thing I only find on Apple platforms, particularly with their own apps. As much as I liked Google Play Music, you couldn't do it there, and I just checked Spotify and it doesn't let you do that either.
To reveal the filter field, you must select the "View" menu, and "Show Filter Field". Worse each time you relaunch Music, this field is again hidden, and you have to select the menu item again.
people discover these touches in the breech, when they need to move on for some reason or other, and all that's familiar is lost. in the words of Joni Mitchell, "you don't know what you've got till it's gone"
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.
I probably would have to do it at some point if Apple decides to completely deprioritize it.
For now, Objective-C even has some benefits. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.
Also - how did you do the visuals in the "Gnarly Bits" section that split the page/components out into verticals? That is such an amazing way to display the internals of a thing like a page.
If these elements could be packaged into a blog theme for whatever blog hosting platforms are popular these days I bet you'd get a bunch of people to purchase. Nice work!
The component split is done by hand in Figma with regular screenshots and cropping. I also used a plugin for skewing.
IMO customizing scrollers is almost always a disservice to users.
It's a single form-over-function thing that I could not resist not to add. :)
I've expanded it by default on bigger screens now. :)
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.
C# is a totally different story.
Interesting. Can you share more details?
C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code.
Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues.
The difference is really about what the stated goals of the language were/are.
Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple).
> All new code is in Swift.
False.
> All new frameworks are Swift-only.
False.
It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong.
My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
Which assertion was wrong? I was paraphrasing from the project page itself:
"It is in its early stages with many features still to be implemented." https://github.com/apple/swift-foundation
Your original assertion that Apple wasn't rewriting anything.
I have no idea what you're talking about. I made no such assertion.
Perhaps you're confusing me and "toyg"?
My point, as always, is the truth. You said two false things, which you subsequently admitted were hyperbole. Truth is valuable in itself, and more important than "points", i.e., arguments or motives.
If I were to make a point, though, it's that Objective-C still has a very long life ahead of it, and its complete replacement, if that ever occurs, will be an arduous process, given the amount of extant Objective-C code in the operating systems and first-party apps (not to mention third-party apps). It's not just Objective-C either: C++ is also used quite a bit in the OS. Think of WebKit, for example.
By the way, we could be hired, for the right compensation. Nonetheless, companies almost never try to recruit me, but they still whine about how "hard" it is to find ObjC developers. They're not even looking.
Besides, experienced engineers can learn a new programming language. Do you think that every engineer Apple hired before 2014 had Objective-C experience?
Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago).
https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
That was a bit rude and unnecessary.
Why do you say that? Do you have experience backing up that estimate?
I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043'
In C++ I'm dubious you couldn't throw an exception instead of dumping.
[1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.
I definitely wouldn’t call Swift a 10x improvement in efficiency, and I like coding in Swift. I do advent of code in it each year, but spend a fair amount of time just fighting with the compiler–after all these years, it still emits strange or just flat out incorrect diagnostics.
Pro features are $10/month, but are actually also "free" via an unlimited time trial.
The $10/month price tag is to support the developer if you're so inclined, which includes some nice-to-have features.
Would it be possible to have a basic mode where one makes a one-time payment and has the option to hid all nagging about "Pro" features?
Enjoyed even the transparency on pricing thinking, but one price that doesn't seem to have been experimented with is allowing a one time purchase that is not an in-app purchase.
In-app purchases make your app unavailable to company employees where the company manages the Apple device using MDM and purchases software using e.g. Apple Business Manager or the older volume purchasing. The $99 option should also exist as a standalone retail version so a company can buy the app for employees.
For small app makers: you might be surprised that a company-managed Mac with a company managed AppleID cannot use in-app purchases. Apple has no way for a company to do IAP for an employee, and in fact the employee cannot do it themselves either. For such users, you must either (a) allow retail app purchase, or (b) have an out-of-band subscription purchase and management, like Microsoft M365 or Adobe Creative Suite.
Whether you do it out of band or as a one time retail purchase, if you do track logins, you should support the simple "Login with" or "Continue with" buttons for Microsoft to hit the 85% of small businesses with identities on that platform, but also Apple and Google. These buttons are easier to add than devs might think. You don't need "SSO" to let most companies log in with company IDs.
I've always avoided non-App Store distribution to keep things simpler. It's a nightmare to manage many different licensing schemes.
Now I don't have to have any backend. Everything is done via the built-in, robust App Store mechanism that just works.
I hope Apple will figure something out in the future. And I think they will since they want to increase their "Services" revenue as hardware sales decline. Making stuff easier for business customers seems like a low-hanging fruit.
So you'd have 2 apps listed:
- Paper (Lifetime) ... $99
- Paper ... Get
Companies can buy employees the first one because it has a price.
> Everything is done via the built-in, robust App Store mechanism that just works.
Good call, and so true.
Hm. I feel like having 2 apps could confuse some users. But maybe it's worth it. ¯\_(ツ)_/¯
This has been going on a long time, once upon a time it was used for Free with Ads versus Paid: https://www.kodeco.com/2404-how-to-create-both-a-paid-and-li...
See also this discussion, mentioning family sharing though instead of mentioning corporate purchasing: https://apple.stackexchange.com/questions/243954/which-purch...
I'm not at work so I can't readily pull up a list of the apps we can and do buy employees thanks to having a paid version available, but there are quite a few, and they win out over more popular apps that have only IAP.
I searched for "Pro" and found a sort-of example:
- Korg Module (Get+IAP): https://apps.apple.com/us/app/korg-module/id1048875111
- Korg Module Pro ($39+IAP): https://apps.apple.com/us/app/korg-module-pro/id932191687
(These are not productivity apps for employees like companies are looking for, just an example done at both price points.)
Anyway, if you had a $99 paid version, our company would buy copies for employees.
I think the regular, unsophisticated user might still be confused. I already envision questions like: "Should I buy a lifetime license in the free version or the paid pro app?". There are also additional hurdles like, for example, reviews being divided between 2 separate apps. I don't know, maybe it's worth it, but I am hesitant. I want to keep the whole experience of Paper simple, and this just adds complexity. I would prefer to wait for Apple to solve this at some point in the future.
Paper does support family sharing, by the way.
I will ping you on LinkedIn if and when I will make a separate app.
So my worries about confusing users are baseless.
I can put a link in the description of the main app and businesses can purchase the app from the link. Sounds amazing!
Here is the link:
https://apps.apple.com/app/id6476067130
I too find it very annoying, especially for such a long article.
It expands in the app as you hover over it. Probably needs a similar thing for the website.
Or I just need to give up and revert it to the standard one. :)
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!
It's hard to do when every popular platform seems intent on making it unusable.
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:
(The key to it is the background-clip property, that lets you use the border to control where the background is drawn.)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
Seems to work.
Thank you!
I have a copy of IA Writer that I've somehow never used, so maybe I'll buy this to add to the pile.
There's occasional spam, but the barrier of having an Apple device to spam is enough to not make it a problem.
> By the way, I also use categories to shorten long framework methods. The underscore at the end helps to avoid clashes with public or private methods that Apple might decide to add in the future.
I think you already know what will happen if Apple adds a method (public or private) called text to NSTextField or stringValue to UITextField in the future ;)
I don't know, what will happen?
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/AppKit.
I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
It's like you go through a SwiftUI tutorial placing @Published and @ObservedObject everywhere, and then once you're writing the app you realize what you need is Combine except you haven't learned that yet
Looking inside the BBEdit app, I see some Swift in BBEdit.app/Contents/Frameworks/CandiedYams.framework, which appears to be a third-party framework (CFBundleIdentifier org.darkrainfall.candied-yams), but not much else.
I've been using BBEdit for about thirty years. It's been through many changes. I suspect that he's pretty conservative.
Apple's stubborn and bizarrely proud insistence on not providing the full solution here is very annoying.
Those seem like very basic features that a UI framework needs to get right.
I’m having a lot of fun with it at the moment. If you stay within the bounds of how they encourage you to build the apps, you can just go go go and with very little work release a fast, stable, native app across all their platforms.
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.
I kind of wish that SwiftUI was a clean break in some ways and did not depend on UIKit and avoid all the abstraction leak issues that have been arising as a result. I know that would never happen in practicality although.
We need more apps like this in every category.
Many many years ago, I used to run a web hosting company. One of the first things I did was I built one of those little chat widgets that let me chat directly with visitors on my website. This was around the year 2000 and before I had ever heard of liveperson which was somewhat new at the time. That single feature did more for my business than anything I did. Because I could talk directly with customers (and potential customers), and because I was the sole decision maker for the business, I was able to say yes to ridiculously obscure requests for features that were easy to implement but very valuable to just one specific customer. My hosting business never grew into a large company but it did support me through college and for a while afterwards.
I was a really powerful sales and support tool.
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 'learning' experience in a positive way. Really nice.
likewise, 80% of the tutorial is preamble to prepare for the 20% you care about.
just don't.
And it's still the most useful guide to setting up Qt because it's the only first-page result that mentions Berkeley.