> It took a few hours to fall in love with SwiftUI.
> It was in development for 12 months. It would have been less if SwiftUI just gave.
> At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart.
This may be useful to someone trying to create something:
In terms of software engineering, you took "a few hours to fall in love with SwiftUI." There could've been more evaluation done: reviewing existing complaints of SwiftUI, implementing the most challenging parts of your UI as a sanity check, or trying it in a small side project, hiring a developer that has used it before, etc. Also, why count lines of code, as opposed to describing features and challenging technical details. Lines of code doesn't signal anything (e.g. effort, quality, time spent, features, is it code generated?, etc.). Every line is an extra source of bugs.
In terms of product development, it took 1 year to ship the product, so after all that, you don't know if you have customers. That's fine for a side project, but this is a "bootstrapped operation behind schedule".
Alternative: I hear Flutter is quite productive. If you one to fall in love with technology, you'll like Flutter.
I am a heavy user of Flutter. Even for simple things if I need to throw together a UI for my own use and then throw it away, I default to Flutter simply because I have become proficient at boot strapping a Flutter project. This is especially true now that they support desktop applications.
For this application, it sounds like the underlying services are not very platform specific, so on that level it seems like Flutter is a good choice. My concern would be that the developers seem very focused on the quality of the experience of even micro-interactions. My experience in Flutter would say that this degree of attention to detail would be hard to get right with Flutter, especially without choosing a platform to focus on, in which case the cross-platform benefits of Flutter are minimized.
Whether delaying an MVP for months to achieve that quality in the user interactions is an interesting side debate, though.
The problem with solutions like Flutter is that many apps, especially iOS apps (though maybe not a calendar app), will often use powerful platform features on iOS that are not so readily available on other platforms, so some degree of platform-specific code is always going to be there -- maybe a lot of such code. For example, the amazing Core Image library, or writing Metal kernels (increasingly common since it is rather easy to leverage GPU compute on iOS and offers tremendous performance benefits), and other tools. If you are going to interact with that in Swift anyway, adding a new language and UI framework and extra layer of abstraction and communication to your app may not make sense.
Flutter makes the least sense from all the cross platform technologies.
React Native has 1000s of people with experience in React, with experience in JavaScript/Typescript. There's people with 10+ years of experience.
There's a very small percentage of Flutter devs, since Dart is barely used in Flutter. It being very knew, there's almost no one comparatively.
If you're a company and go with Flutter, you'd be constantly trying to find people for your project.
Even if Flutter is 2x as faster to write code for or 2x as performant than React Native, etc - it doesn't matter if you can't find the people to scale and churn.
Then there's the whole "when will Google kill it" with them doing Flutter and Jetpack Compose and then there's also Kotlin Multiplatform (not from Google), it seems like they're a layoff away from shutting it down.
You know Meta will keep React Native around for decades, since a lot of their stuff is built on it.
Flutter has massive performance issues, is based on a dead end language nothing else uses that lacks basic features, and worst of all is essentially Google developed.
Native devs are going to make a lot of money rebuilding apps for companies foolish enough to base their entire company on a Google “product”
Have you written anything in Dart? I found it super easy to pick up and fantastic to write code in. There weren't really any specific features I found missing in the language.
Not all apps require 120fps performance either, mine was just buttons and feedback from the backend.
Flutter was actually perfect for this application.
> we wanted to move our entry UI to open in a sheet and with immediate focus on the title TextField, but there’s a noticeable delay before the keyboard pops up. So we didn’t.
> when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible.
That such basic functionality is not possible is astonishing. Especially the first one should be a common use case.
I agree, in latest swiftui versions what they want is possible. The same with the keyboard opening and closing when pressing next. There’s an issue elsewhere
I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent with UIKit and doing all sorts of custom controls and animations, and to abandon that comfort and productivity for another...year?... of a frustrating learning curve does not entice me to give it a try.
But I love the declarative paradigm so much; if only I could easily bring in my toolset of choice, whether it is Elm, Redux, etc, with all the power that native controls on iOS have, that would be awesome. SwiftUI is the only valid answer, but wow, I cannot get motivated to go down that rabbit hole.
It's a great solution when it works. MapKit and web views are good examples of it working well, but it can get buggy with anything more complicated, especially when mixing Views and UIViews in the same parent view. The worst part is that the behavior can change based on the OS version. You have to be proactive with testing your apps on the beta OS releases ASAP.
Also, and this might have been fixed already, but a couple years ago, there were problems getting updateUIView to run in response to ObservableObject updates.
The promise of UIViewRepresentable is a lot like SwiftUI itself. It's great when it works, but there's little you can do when it doesn't.
Or you can structure your app in UIKit and build custom views and nice animations in SwiftUI. SwiftUI is a nice abstraction but a lot of it is really unnecessarily force fed by Apple because it helps them get more amateur developers into the platform.
> if only I could easily bring in my toolset of choice, whether it is Elm, Redux, etc, with all the power that native controls on iOS have, that would be awesome. SwiftUI is the only valid answer
Time for the obvious question: Why not React Native?
I work with a big pharmaceutical company that you've heard of (one of the vaccines), they have a big React Native app that they use to run their studies.
2 years on, their RN devs can't get the app to compile with M1 macs, so they all use Intel macs. They can't update to a recent RN version (recent, not the latest), because a RN navigation library has an issue with it and they're just sitting around, waiting for someone to fix the open source library...
I could go on with the multitude of dependency hell issues they're having.
I only have a passing familiarly with iOS development, but I wonder if it would be possible to lay a declarative-ish data binding layer over the top of UIKit?
I mean I guess that’s sorta what React Native does, so it must be.
Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases.
IIRC the reason why SwiftUI isn’t a separate library is that it’s developed in lockstep with Swift, meaning that each release is dependent on new features in its contemporary release of Swift.
That’s a problem because they stopped building Swift into third party app packages a few years ago in effort to bring down app download sizes, but that means that apps have to deal with whatever version of Swift comes with the user’s system.
The best middle ground would probably be to ship Swift as a periodically updated package.
Couldn't they just separate swift runtimes from the os updates? I'm always baffled by how often features are tied to seemingly random os versions.
For example: You can't debug IOS 14.5 apps on Big Sur because Xcode for some reason needs Monterey. Though if you just spoof the required version in the xip's app manifest it'll work mostly fine.
> Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic
Is it?
Should I expect my M1 macbook to break in unexpected ways for a decade before it works too? M1 is new, like SwiftUI is new, how come it actually works?
> It’s the same company, they should be able to leverage their past knowledge.
It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc.
I don't know why this is being downvoted. The situation is more complex than this simple comment, but the sentiment is correct.
The reality is that AppKit has had its ups and downs recently. There are obviously people in Apple trying to do their best to patch things up, and there have been some nice improvements because of their efforts, but some really bad bugs have been introduced, only to sit unfixed for years. It's gotten to the point where I dread the yearly OS updates, not because I dread having to update my code, but because I worry what has broken.
In my experience, if you don't get your bugs filed within the first week after WWDC, they'll never get fixed, and even if you do, it's a toss-up. But testing your existing code isn't always enough. If you're writing new code to take advantage of some of the new OS features, you can be a month into the beta cycle before you find a bug, and by that point, its too late.
The worst part is that new things are often completely broken or outright missing in beta 1, and then by the time you can actually test them in beta 3 it's too late to report bugs and have any real hope of them getting fixed.
Quite the opposite. I would argue that macOS (the artist formerly known as Mac OS X) is quickly being transformed into iOS. Big Sur was a massive change in this respect, and the transformation continues in Ventura.
So Microsoft's ARM based Windows RT should have been able to run any x86 software, because Microsoft had been coding Windows for a long time?
Sorry, but it takes time for new things to gain functionality and polish. Windows RT was from 2012, and running x86 software on ARM only became possible recently.
Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.
Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?
I don't think the time lag between the first release of Windows on ARM in 2012 and finally gaining the ability to (badly) run x86 programs a decade later is comparable.
>I’d have only Slack open, and switching between channels would still take almost three seconds (yes, I timed it on my phone). Spotify, also with nothing in the background, would take 11 seconds to open, then be frozen for another four seconds before I could finally press play. When I typed in Chrome, I often saw significant lag, which led to all kinds of typos (because my words weren’t coming out until well after I’d written them). I’d try to watch YouTube videos, and the video would freeze while the audio continued. I’d use the Surface Pen to annotate a PDF, and my strokes would either be frustratingly late or not show up at all. I’d try to open Lightroom, and it would freeze multiple times and then crash.
It quickly became clear that I should try to stick to apps that were running natively on Arm.
SwiftUI and UIKit compose well in both directions, so if you choose SwiftUI as your framework, but then run into a wall, it's an option to partially rewrite that difficult part with UIKit.
Of course if the problem is with the core of your application like the scrolling example in the article, this is not going to help you much.
the worst isn't mentioned : not only is swiftui causing all kinds of glitches of it own, but despite being a brand new framework, it still locks you 100% to apple devices.
I mean, i had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering, making at least part of the code reusable somewhere. But no, still 100% lockin. Which to me is a HUGE missed opportunity.
What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve.
People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.
Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.
Swift is in considerably better shape than Obj-C is when it comes to cross platform. It’s not perfect, but it’s at least usable (there are production back ends written in Swift for example), it’s been slowly getting better, and Apple recently committed to filling many of the holes/inconsistencies in cross-platform with their announcement to rewrite Foundation in Swift and make it open source.
By contrast, Obj-C couldn’t even allocate memory without the assistance of AppKit, UIKit, or GNUStep. On its own it was woefully incomplete.
As for UI frameworks, porting SwiftUI would be a tall order with how it’s partially built on top of AppKit/UIKit. The most we’d probably get if it were open sourced is the surface bits, not the underpinnings.
Chris lattner had very clearly stated objectives for the language, and at some point cross-platform swift was a real possibility : at the time when a few server framework were created and when people at google were using it. Why this never lasted, i don’t know (my guess is the reason was purely political).
Unfortunately all those options got cancelled, and now apple remain on its own using it. I don’t believe in cross-platform swift anymore.
Apple’s business goals are for 1P and 3P apps to provide the best app+device experience on Apple hardware. Everything they to is to that end, since they make their money from selling hardware.
A programming language thriving is a secondary or tertiary goal.
Except the end-result of that policy is that 90% (made up number) of the app on the store are made with cross-platform tools, because very few can afford 1/ learning a language just for one platform 2/ not reusing any code at all between platforms.
I don’t think swift has any future in the long term unless they go multiplatform.
You're talking about a company that continues to support a crappy macro system named after themselves, first released 30 years go, that absolutely nobody else supports or cares about.
They just don't care. Apple will do what Apple will do.
> I had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering
LOL!
Any other vendor: Big maybe (Microsoft figured out a few iterations late that it might help against being left behind). Apple: Of course not.
Even for their cross-platform services they'd rather make the same app twice than accepting even a 20% higher likelihood that iOS apps also get released on Android.
Aside from any quirks in the rendering model -- at a more fundamental level I can't imagine what apple is thinking with the observable object data modeling approach -- and what [seems to be plans](https://forums.swift.org/t/pitch-observation/62051) to expand it ... it feels like the ObservableObject style modeling approach has been tried a million times in various frameworks and always results in complex and difficult to debug systems -- codebases which make it inherently incredibly difficult to reason about "what happens when this data changes"
A Unidirectional flow + data flow-like solution makes so much more sense to me as the basis for sane data modeling for ui's ...
Given that a predominant paradigm in apps is the infinite scroll view that receives updates, it’s a tragedy that SwiftUI does not ship with a rock solid implementation and instead succumbs to jitter and scroll-into-view issues.
The trick for 1) is to use @Observed object on a state class inside your app struct then push to views via @Published combine streams so you can map/filter/reduce. Storing massive state in every view/child view/grandchild view is both stupid and wasteful.
EvironmentObject is a total foot gun for performance and causes a bunch of other issues. Core Data and SwiftUI are also awkward together. We ended up keeping Core Data at arms length and building our own internal framework to do dependency injection.
This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference counting. This last got rolled into Swift, and hours spent looking for memory leaks or dangling pointers become a thing of the past. It is still possible to have memory problems in Swift, but mostly they can be avoided.
In the case of UI, use of a library is essential. And of course boring technology has libraries. But the real problem is layout: not just where your elements sit on the page, but where they go after the user resizes a window. In the early years, this was not too difficult because screens were mostly fixed size and in landscape mode. But now there are many aspect ratios, four possible orientations and so on. Apples earlier solution was a system called Layout Constraints. Frankly I found them really difficult to use, even when I stuck with the ones provided within Xcode. SwiftUI seems to me the exactly correct way to deal with layout complexity. Admittedly lots of it needs to be improved (as the article points out), but I would much rather use a declarative approach to layout than any alternatives I know of.
For an expert with some mathematical intuition layout constraints can do a custom layout that lays out perfectly on all screen sizes much better than declarative. However there is a learning curve I admit.
I love AutoLayout constraints…unfortunately Apple has never improved debugging tools. So when the system breaks and spews a bunch of autolayout constraint complaints to the debug console, it can be difficult to determine what went wrong (especially because the system will sometimes generate its own constraints, like if you are using stack views, and you have no insight into why they were generated or why the system is ignoring and discarding the constraints you made).
Apple’s documentation has also gotten way, way worse. Apple expects you to watch the WWDC videos, but it’s not like they make refresher videos on old topics all the frequently and they often remove or hide old videos.
When they introduced auto-layout, I started using it all the time. The debug spew from the console was definitely frustrating to debug though.
Eventually I tried going back to manual layout because a coworker still used it all the time and I noticed that it was pretty easy to follow the layout rules in imperative code (so long as it's well-structured). Since then I just do manual layout for everything. It's just easier for my brain to describe the layout I want that way. I feel like it takes me longer to come up with constraints that match what I want, but I'll admit if I went back to auto-layout, I'd probably be better at it.
Yeah there is a learning curve I admit. Usually you try to change the size of your view and see how things resize.
And yes StackView is your biggest friend. Usually when the system ignores your constraint it says that on the log. It can be a bit tricky to find out which constraint its breaking but the View Debugger and also the constraint constant value can help find it.
What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?
I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult.
The reason I suspect people don’t think scrolling was ever an issue (especially on iOS, I doubt Androids will share the same view), is because Apple spent so much time getting it right for the original iPhone. Correctly identifying that scroll behaviour was a kind of “killer app” for touch screens.
But in order to make that scroll behaviour so rock solid. They heavily constrained the problem and did bunch of visual tricks to make it appear smoother that it actually was. Most notably, native scroll views generally required that every individual scroll element was an identical size and shape. So you could cheat during the scrolling process by not actually rendering all the content while scrolling, just rendering the UI chrome (which was identical for every scroll item), and loading the content once the scroll velocity was low enough that there was time to load and render the details before they needed to be displayed.
The other thing that happened, was basically stopping any other compute from occurring. When you scrolled on the original iPhone (and for many generations afterwards), your phone basically dropped everything and dedicated all its compute to just scrolling the view. Not even code to compute the content of scroll elements was executed, you were expected to have done that before the scrolling started. This was most obvious in Safari, where JS execution was halted, and even page rendering was halted, so if you scrolled beyond the boundaries of what had already been rendered, you just got white.
With modern frameworks (and especially the web) there’s been a strong desire to deliver scrolling with a completely arbitrary set of scroll elements, that can all be different shapes, sizes, colours and trigger all manner of background computation. Modern devices are broadly capable of delivering that, but care is needed to exceed the available compute. That’s different from historical native frameworks, where they simply didn’t let people have that kind of flexibility. You got the handful of options the framework gave, and that’s it (which is why older iOS app all had identical scroll UI).
Scrolling has never been trivial. It’s very hard to build abstractions around it. For example UITableView required quite a lot of boilerplate and manual edge case code. Android’s abstractions have very similar issues.
So no, it’s never been a solved problem just like UI abstractions have never been a solved problem, so solved that there’s nothing to improve or explore.
Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the battery as your device will doing orders of magnitude more work than necessary. You don't encounter lists of this length as often on web apps, but the same issue would apply if you did -- why do you think infinite scrolling only loads a few rows at a time until you scroll further? And how many times have you been on an "infinite scroll" web and as you scrolled, you had to wait for it to do the work for the next scrollable content. Happens to me often. Now take all those concerns and bundle them in a UI that is suppose to manage all this for you automatically via declarative behavior, and you can see why it's not as trivial as you suggest.
Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.
Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed.
Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered.
Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…
Filling polygons has never been the hard part of realtime games. It's all the work that gets you to be able to fill just the polygons you need in the way you want them.
It is not a big ask to have a scrolling UI. Look at motif from 80s.
Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose.
Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.
Infinite scroll on web also rarely recycles elements. It’s more common for sites to leave elements sitting in the page with memory usage gradually creeping up as you scroll. They largely depend on you not scrolling far enough for that to become a problem.
Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem?
It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.
I don't think this is true, I recall an interview with the original Instagram people saying that it was not possible to scroll with that many photos and text being live rendered and they had to fake it with something like pre-rendering the UI as an image and scrolling that.
Scrolling on SwiftUI is extra bizarre because I often observe weird micro stutter. A scroll view with perfectly static text that never updates will sometimes scroll at what seems to be ~45fps. But really it’s more like it’s randomly dropping 1 out of every 4 or 5 frames or so. It also seems to be related to dragging the scroll view, because programmatic scrolling can be very smooth. (Also SwiftUI was weirdly capped at 60hz and couldn’t do 120hz until iOS16.2. Doesn’t make me confident that SwiftUI will ever get a lot of development love from Apple if it took over a year for SwiftUI to support a flagship feature from the iPhone).
That isn't true; scrolling (and resizing) was a performance sinkhole for all kinds of apps that used the native table views (NSTableView and NSOutlineView), for many generations of Mac OS X.
They eventually added enough optimizations and performance cutouts to make it pretty easy to not fall in the hole with your app, so it hasn't been a problem with AppKit (or its younger 85% clone, UIKit) for a long while.
But I'm not surprised to hear Apple's much newer and not-very-related UI toolkit still has lots of those problems. That's one of the problems when not many developers actually use a technology — it's not just a popularity contest, having lots of users who complain is how you find a lot of the bugs and performance issues in your UI toolkits and app frameworks.
So lack of popularity often does mean there are probably a lot of those.
What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?
Xcode sometimes takes 20-60 seconds to recover from errors in the syntax. It’s so odious that when I have to use it, I build everything in VSCode and then do the final mandatory testing pass in XCode.
It’s extremely slow on high-spec MBP.
It sometimes takes developers over 14 hours to update.
It interferes with other command line tools, forcing itself into the middle — if you’ve ever tried to run git on a fresh MBP and run into the xcode-select install step, you know this one. It’s a bad citizen.
Installing XCode will cause a perfectly functional machine heavily used for development in VSCode to experience several full crashes until it fully takes over the machine. MacOS with and without XCode appear to be two fundamentally different operating systems.
Having XCode running for any amount of time saps battery like nothing else. You can run VSCode for 24 hours on a MacBook Air with M1 for maybe 3 hours in XCode.
The git integration is so utterly crap and broken that it’s safer to turn it off rather than fighting the secret intermediate repo cache that it hides from you and sometimes forgets to update.
For some idiotic reason, creating a new file in XCode prepends the file with a comment block including the name of the file, the date, and the name of the user. Who asked for that? For a file that’s part of a repo that’s going to be touched by multiple people over a long period of time and likely renamed, this is just obnoxious noise.
> creating a new file in XCode prepends the file with a comment block including the name of the file, the date, and the name of the user. Who asked for that?
This is standard corporate policy at most/all big software shops. Apple uses Xcode internally, so the format and contents probably reflect their policy.
The block can be customized for your policies -- or removed completely, if preferred.
However you might have some other issues with your system because I practically never close Xcode and I’m having like +10 hours of battery life on my M1 air. This includes actual work being done in Xcode.
That’s probably true, but also I’ve experienced these issues on two different machines (high spec Intel MBP, highest spec M1 MBA).
I do regularly find that mDNSresponder has been sending and receiving 100’s of GB over the network and must be force killed. When that process goes off the rails, it also saps battery.
I wish that I didn’t have to keep Activity Monitor open at all times on both machines just to keep ahead of the problems. It’s not like effectively running top is cheap.
Xcode doesnt even support features like format on save nor does it have powerful enough api to support a mod ecosystem to fill in its gaps.
It has all sorts of bugs and weird fail cases.
Honestly you should just search the internet for testimonials because anyone who uses Xcode can create a list of issues rather than rehash them all here in response.
I grew to dislike mods and ever growing features. Lately I'm experimenting with Swift Playgrounds and I start liking it very much precisely because lacks a lot of features but its still capable do a lot.
So many features and linters and tools end up building a huge cognitive overhead, which is the primary reason I haven't been touching JS since a few years. The JS world piled up so me sh*t in order to make the working with JS something that is not, that I found myself not having energy and time to do something other that setting up tools and frameworks.
What I want is to be able to start coding like start writing an article in a Word document and Swift Playgrounds is getting there. XCode was good too but wasn't anything special, Swift Playgrounds is amazing.
I'm especially excited for WASM, so maybe I can just write everything in Swift eventually.
For starters, that Xcode's "vim" emulation doesn't even support arguably the most useful, common, and productive operator in vim -- the dot -- is embarrassing. So many developers depend on vim-like interaction for significant gains in productivity, but Xcode only got about halfway there, and not the better half.
2) It's extremely buggy, like on a daily basis where something just doesn't work for any apparent reason that is usually either fixed by killing Xcode or removing derived data & then killing Xcode
3) Lack of plugins for even the most primitive of features like autoformatters
4) XML for build configs inside .xcodeproj
5) Why does it take half a day to update through the App Store?
I mean it has some nice features functionality-wise, such as the metal debugging toolkit, but the experience of actually coding in it is abysmal. Like so bad that I've been doing as much of my Swift work in VSCode as possible, which Xcode actually prevented for a while due to a bug in how it handled local Swift packages.
1) I use IntelliJ for my day job and find it much slower than Xcode
2) yes
3) I don't really use plugins in IntelliJ either - I do in VSCode but only because it's pretty useless without them
4) Not sure what the problem is with this, but I will say I prefer Package.swift projects for anything that isn't targeting a UI runtime
5) App Store update process just doesn't play well with 8GB applications. Either delete it and re-install from App Store or use something like Xcodes.app
On Apple Silicon it's quite performant, I'm sure there are faster things but I don't have complaints on speed o M1 Air. I had complaints on my Intel based mac though.
The bugs can be annoying but they usually go away after restart and cleaning the junk.
> 5) Why does it take half a day to update through the App Store?
But this one is really annoying. Also for some reason in downloads and installs TWICE.
It’s way, way faster and easier to just download new versions of Ccode from the developer website. I have no idea why doing it through the AppStore is so slow. If you pull up the console log you can see the AppStore app not actually doing anything for 20-30 minutes (even though it’s displaying the download spinner) before it finally decides it’s time to start downloading.
I spend most of my day in Xcode and for a while the main frustration was SourceKit being slow/crashy. That’s improved a fair deal over years, but I’ve found that the best thing one can do to improve that, as strange as it sounds, is to avoid code smells.
SourceKit can get really grumpy with things like deeply chained optionals, deeply nested blocks, and lots of casting or otherwise fighting against the type system. Not doing those things makes it run significantly more smoothly. So if Xcode starts bogging down or SourceKit is crashing, it means there are probably cleaner ways to write whatever I’m currently working on.
I still have no idea how I can quickly switch back and forth between open files. Either the feature is entirely missing, or completely unintuitive to discover and/or use.
For the record, I am writing this message in 2023.
Have you tried Swift Playgrounds? All the heaviness of an IDE goes away, it feels light as a toy but can do all the basics very well. It has some annoyances but the "opened a file and start writing my code, didn't bother with anything else" vibe is there.
The Swift team released a VS Code plugin recently. As far as I'm aware, it doesn't do live preview, but considering how often Xcode fails to render live previews, I'm not seeing that as much of a loss.
How does everyone feel about hiring iOS devs in this environment? I feel like its too hard for SwiftUI devs to pick up UIKit when they get blocked and usually they just give up. Also in interviews junior devs have no clue about AutoLayout or UICollectionViews.
Is it possible to write an application of this scale with flutter without (or very little) infecting swift? probably can be written, but I would like to hear comments about what can be experienced in terms of performance and development.
I think the author was just pushing the boundaries of iOS development too much. You could tell in the app that the UI was complex and some guidelines were not followed. This is the consequence when you over engineer and over design and being fancy.
> It was in development for 12 months. It would have been less if SwiftUI just gave.
> At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart.
This may be useful to someone trying to create something:
In terms of software engineering, you took "a few hours to fall in love with SwiftUI." There could've been more evaluation done: reviewing existing complaints of SwiftUI, implementing the most challenging parts of your UI as a sanity check, or trying it in a small side project, hiring a developer that has used it before, etc. Also, why count lines of code, as opposed to describing features and challenging technical details. Lines of code doesn't signal anything (e.g. effort, quality, time spent, features, is it code generated?, etc.). Every line is an extra source of bugs.
In terms of product development, it took 1 year to ship the product, so after all that, you don't know if you have customers. That's fine for a side project, but this is a "bootstrapped operation behind schedule".
Alternative: I hear Flutter is quite productive. If you one to fall in love with technology, you'll like Flutter.