The ability to go low/no-dependencies, as mentioned in the blog post, is one of my favorite things about Apple platforms. It’s not just possible but practical to build a capable, highly polished app without bringing in anything third-party thanks to the richness and depth of AppKit/UIKit. Few frameworks can compete, with even other juggernauts like Qt coming up short in comparison.
I've built my note-taking app[1] in Qt, and while I worked hard to make it look good, I'm very satisfied with the result. Also, it turns out to be much faster than comparable native apps (performance benchmarks available on the website). [1] https://www.get-plume.com/
You have one of the few Qt-based apps that looks and feels like it belongs on macOS. Really well done.
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 t…
Only very tangentially related, but I think the generated Markdown shown in the last screenshot under "Gnarly bits" is not correct? It contains `[**Alfred Nobel]( https://en.wikipedia.org/wiki/Alfred_Nobel ) for this prize.**`, with the bold starting inside and ending outside the link; I don't think that's possible. It should either start outside, or have two sections of bold text (inside and outside the link).
The Markdown engine is bespoke. I don't follow any specs. Paper might be looser in what it allows than other Markdown editors. Practically no one had issues with that over the years. :)
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 w…
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.
Often worth it for superior UX. The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
You can write app that will work on Windows, Mac, Linux, iOS, Android using Delphi.
The Windows 7 example on their home page does not inspire confidence. I'd much rather be locked into macOS than be locked into this
The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows. Cross-platform applications have their place, but sometimes I like h…
What I find bizarre is that this is often discussed without considering the specifics of the app. I agree that not every app must be cross-platform. Text editors are a good example. The economics may or may not be more difficult. Yes the audience is smaller but the cost may be lower as well and you may have a competitive edge over cross-platform apps. The problem with starting a single platform app is that you have t…
> The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features
I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason
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…
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 improvem…
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)
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.
I have not investigated it, to be honest. If it's as easy as switching the compiler to Swift, and everything remains working as is, but I also get to use all the Swift stuff in addition to Objective-C, then I am clearly missing out!
They are separate compilers. Obj-C is compiled by clang, Swift by the Swift compiler. You enable bridging in Xcode and then get access to your Obj-C code in Swift through the use of a bridging header, and Swift in Obj-C through the use of the *-Swift.h generated header. You can write classes in Swift that are visible to Obj-C and vice versa. You can't expose everything from Swift to Obj-C since Obj-C is missing most of Swift capabilities, but it's easy to call back and forth.
> 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.
There are a bunch of design decisions in Swift that make it more C++ with the corresponding binary bloat + other issues than reference counted Java/Smalltalk with a C FFI that Obj-C is. You could've had Obj-C without the C for example, ADTs (enums), strong nullability enforcement and a nicer syntax while reusing most of the Obj-C core and retaining the compile speed, rock solid / fast debugging, function calls as dat…
Sounds like you want Mojo, Lattner's statically typed language built on Python. In any case, the language you describe wouldn't be compatible with Obj-C except through an import layer like Swift. "Obj-C without the C" is meaningfully impossible.
And it's funny you mention systems programming, since Swift is still relatively bad at that compared to C++ or Rust, and most of its improvements in that area are recent and ongoing. It'll be another release or two before the memory movement features are fully in place and the language allows full control over ownership (without unsafe heroics at least).
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.
Hell it's 2024 and I find myself translating Objective C into Swift