What is Swift? Why Swift? A lot of discussion here touched this topic. My experience here after 10 years with Swift, starting from version 1. This is how I understood the language through the process of creating several apps (and web services) of non-trivial complexity.
Swift helps those who want to build end-user products.
Swift is the language for those who need to deliver end-user products, deliver fast and iterate often with minimal friction. You got to be a practical creator who needs to create and deploy to market fast. It's all about achievability of end result within modern world's time constraints. This is where it shines.
Swift may not fit more pure paradigms.
If you're after the pure art of programming then other languages may speak to you better.
In other words, Swift is extremely PRACTICAL – meaning create, deploy and earn living – and is squarely focused on people who need that. Naturally, not everybody will resonate with its core mission statement.
It's fast enough to make running an app feel like running a native app – faster start time, less memory used, less power hungry, more responsive UI – compared to browser based cross-platform apps.
One can say it achieves maximum user interaction speed.
For most critical calculations, one can easily integrate C++/C libraries – at the source code level – which Swift can compile, link and call directly.
Or drop down to unsafe features of Swift and achieve speeds comparable to C++. But that's not really needed in most of real life use cases. Convenience is what really matters when it comes to Swift.
It was a positive comment about Swift showing the batteries included there. It is not normal to have such high-level methods for low-level stuff like bits in an integer. Clearly logical operations and rotation is included in all popular languages.
Don't fight compiler. Just give it an extra definition here and there and it will give you back with blazing compilation speed. Cryptic but "sexy" statements bring suffering in long term, it's a bit like raping your own laptop. No one wins.
I especially ran into it when doing last year's Advent of Code. I restricted myself to not using mutable state or custom data types, i.e. structs or classes, writing in a functional style. That style involved a lot of method chaining (i.e. x.map(...).reduce(...)...) and, of course, of closures.
I had to introduce a lot of helper variables to break up my longer transformation pipelines to make the compiler happy.
I hope Swift is not going the way of Scala any further, which I enjoyed a lot when I adopted it early on, but eventually turned into a monster of a language.
Btw., for recreational coding, I moved on to Elixir in the meanwhile.
Yeah, Swift is for creating end-user products, fast iteration, fast delivery. This is where it shines. For recreational coding definitely pick something that reflects your deeper aesthetic affinity, I totally get what you mean.
Not my experience at all. I develop daily in Xcode and compile times are excellent. One can't really compare between TS/JS interpreted languages and machine code generation. Apples and oranges. Swift compiler is fast, faster than C++. In my experience the Golang compiler is the fastest but the language is much simpler. Rust compiler is slower than C++.
As a side note, for some reason people like to bitch Xcode just out of habit perhaps. It's a kind of base line statement. Not my experience either. It's an excellent IDE for the current year of 2025. Helps me a lot and I build end-user facing apps, the proof is the love that users give to my apps. In other words, I have skin in the game.
The compile times are ok, but slower than Rust and C++ in my personal experience. What I was referring to with "compile time issues" is the occasional type resolution issue that hangs the compiler for seconds/minutes, and requires some refactoring to mitigate. This does happen a lot less with Swift 6 than it did with 1-4 though.
I've used a lot of IDEs, and spend plenty of time using XCode. It's the worst I've used by far, and the only one where I feel it necessary to edit the majority of code in a separate editor.
Writing apps that people love makes you a good developer, but says little about the tools you use.
Sometimes people mistake Swift for Xcode and vice versa. If compiler can't figure out type in reasonable time, give it some room to breathe by adding a clarifying type definition. I don't like to fight the compiler trying to bend it to my will. I am happy to offer extra help by clarifying types – magic costs performance. Compiler gives back by blazingly fast builds.
By the way, I am impressed by speed of Swift 6 project builds on Apple Silicon Macs. My non-trivial apps using a mix of Swift/C++/C files (hundreds and hundreds) get compiled in nearly real time. Feels good.
Mistaking Swift for XCode isn't the issue here. Swift is great, I'm just pointing out the issues I've had with it in large projects.
> ...give it some room to breathe by adding a clarifying type definition
Right, but that's the problem - it's the only language I've used where this is something you have to worry about, and it's not like the type system is more powerful. And often, the issues stem from external libraries outside my control. Better compiler errors would help mitigate the issue.
There's a lot to like about Swift, but I also think it's productive to identify the parts that compare unfavorably to other languages.
Xcode regularly crashes and/or ends up leaving garbage in its garbage xml files. The un-reviewable xml stuff is also a garbage of its own making. The build system is intractable. Xcode does not lend itself to segregating builds from dependency fetching, i.e. do all the internet things on one machine and donthe building on a different one. The debugger cocks out at least weekly. Sure, you can make goods app with it. We’ve been making good apps with less for decades too. Other platforms/editors are not as painful, it is as simple as that.
The only thing XML Xcode generates are storyboards and xibs (and schemes also). All of those XMLs are readable. Xcode’s build system is very reasonable (though different than on other IDEs, but that does not mean bad!).
How interesting! Xcode very rarely crashes on me. I don't know why but it seems to work 99.9% of time the way I expect it to work. Its build system makes sense to me. Of course, it differs from other build systems but that's life, I am flexible and can learn things. Just saying.
"Liking" is irrelevant to me. I do use it thoroughly though – I have written Linux containers (web apps) as well as native macOS and iOS apps. I am end-product creator and want my ideas to become end-user products and see the light of day. Delivery is everything.
Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple.
The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella.
Many of my projects use a mix of:
- Swift
- C++
- C
The whole thing gets compiled from a bunch of source code folders with a single command. No wrappers or binary wrangling, simply call C++/C from Swift.
Compile time is really fast for me with Swift 6 onwards.
I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience.
Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed.
Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
As a software guy I’ve been dabbling with poetry for last 2 years [1] as an extension to my code writing. I think poetry and code go together rather well, there are similarities when it comes to elegance, construction and structure.
Liking or not liking poetry is irrelevant. There are some interesting things happen when one actually writes poetry. You are much closer to the source of ideas that can at times feel unique and inspiring.
Generative LLMs can easily mimic style, any _existing_ style. Can they capture a original higher thought form or is generated poetry an extremely smooth word salad?
In my experience, building user facing products requires understanding of user interaction and general human affinities. In the indie developer context, the knowledge of making the app “relatable” is often more important than underlying engineering fits. I have shared some ideas in the discussion at the top of this page (the Time Nomad discussion)…
As an indie developer for the last 10 years my key learning is writing apps for “under privileged” communities. Firstly, it’s a niche. Secondly, people really value your effort and appreciate giving. This creates a nice feeling.
I have created my major app, Time Nomad [1], out of pure curiosity. Don’t laugh, scientific minds… I wanted to see how astronomy and astrology coexisted for hundreds of years without all that new age nonsense that corrupted the ancient discipline.
So I made it different. It’s more of a toolkit to calculate and grok movements of celestial bodies and find moments of specific alignments. That is pure fun. I have enjoyed maths and computational challenges, while the users surprised me by liking the app’s ability to give quick answers about what (and equally importantly when) is happening in the sky — from an astronomical standpoint. No voodoo language needed, just pure geometry.
Why am I saying all this? Taking an old idea and giving it a new modern spin can win hearts. There are communities of people who are open to support that.
Isn’t a big part of your userbase into new age stuff? If you think of it as nonsense, how do you earnestly try to serve them? Aren’t they asking for features you think are bunk?
By sticking to truth and reality. There is integrity in showing the numbers (planetary coordinates, segments of time, etc) as they are, they are real phenomenon.
It’s up to the user to devise their own interpretations. I do not do any interpretations, and that’s by choice. Pure calculations.
And what I have discovered is that all “astrologers” are different. Some are into glossy magazine style horoscopes. Others are more interested in a kind of “celestial statistics” — how and when things align, how movements create harmonics, etc. There’s a rich field of mathematical thinking if one wishes for that.
Everybody gets their own piece of cake. I am happy with what I do, they are happy with the toolkit provided. One can’t judge a pocket calculator for how it may be used.
Funky feature requests? Surprisingly not that often. The reason is perhaps the intent behind the app. It doesn’t classify itself as a “crystal ball”, it’s a calculator. So I stick to what is called “classical astrology”, ie something borderline between astronomy, philosophy and mathematics. Pure foundational basics.
> Isn’t a big part of your userbase into new age stuff? If you think of it as nonsense, how do you earnestly try to serve them? Aren’t they asking for features you think are bunk?
A chiropractor uses maps of human bodies to understand where things are, even though they use the information differently than doctors and surgeons, both groups base their understanding on the same facts.
I'm guessing the same can apply in more areas than medicine too.
The strangeness of the first one is the basis of the field. Literally all of chiropractic practice stems, objectively, from the one guy and his ghost revelations circa 1896 or so.
Exactly that. Instead of fighting belief systems, offer something that is useful for different practitioners. There is massive amount knowledge that can be made interactive and broaden our understanding of reality we live in. And there is an aspect of fun and unexpected discoveries once one decoupled themselves from any kind of ideology. Be outside the box.
Absolutely. So if you made a body map and your user base starts asking for you to add chakras or reflexology areas or acupuncture locations and you think that's all a bunch of woo, how do you respond?
For reflexology/acupuncture, you could have a section where you highlight typical focus points used in reflexology/acupuncture, without giving any sort of positive acknowledgement for them as treatments.
There are factors of both reality and imagination in pretty much everything we do, including things like LLMs. What is considered cutting edge today may be considered sheer quackery in the future.
My perception is that there is value in sticking to reality. Who am I to judge the users? They are free to interpret numbers as they wish. Just look at the big data. The numbers are real, yet interpretations and conclusions can be anything - the interpreter is inherently biased and constrained by their own field of view, political and employment context. Not that dissimilar from astrology, in essence.
Why astrology in this case? My interest has always been in the analysis of movement of planetary bodies. I like to see and understand how things move out there in space. There is a beauty in that, for me.
I don’t think I’d pass any space company interview, it’s too elitist. So I thought, hmm astrology…. but why not? I’d get to play with celestial mechanics. And the users can use it for what they wish. After all, in the past, astrologers always were astronomers and mathematicians in the first place. Perhaps there’s a mysticism in the sky that allows to be equally scientific and inspired? This is the case where belief isn’t that important. What’s more important is to be moved by what one does.
The app itself isn’t something that interests me, but wanted to complement your beautiful home page. Nicely done. You’ve executed it very beautifully. I wish more apps were like yours.
Oh, wow, thank you! I am touched. Since the very beginning I've been using a simple Jekyll template and added some graphics to make it more interesting and appealing. Perhaps the amount of features that the app offers is helping here. Each feature has enough depth to ensure its own slot in the broader narrative.
From my perspective. Firstly, know yourself. Try to identify directions of knowledge you have a natural attraction towards. This phase takes time. Use the sense of curiosity as opposed to common entrepreneurial logic. What would you do even if unpaid? Do a few small projects, explore different directions before committing to something specific.
By the time you’ve identified and experimented with what makes you tick you will have already built an idea of what people discuss on forums, etc. There will be already existing solutions and incumbent providers. Don't be intimidated by them. Read what users say and how they express themselves within that domain. Very likely incumbent providers are “old style” burdened by legacy patterns. People use them because there’s no alternatives.
If at this stage you do have a genuine feeling that you can do better - supported by product vision (that's important!) - go for it. But it has to be real for you. You’ll need enough passion to last through the first year of development. If you will survive that year the chances are you will have created something genuine and there’s some real IP behind your effort. Users will recognise that.
Great-looking website and app. How did you decide on what becomes an IAP and what is core functionality? Why did you disable family-sharing of IAPs (or is that just an Apple quirk on iOS)?
Initially I made the app as an experiment, just wanted to see how planets rotate and align, and what makes people interested in that. That became the foundation.
Then somebody asked “can I have some extra asteroids and minor bodies added?” This became the first add-on I have introduced.
Each time I can think of an interesting feature, I think “is there enough standalone value to classify it as an add-on?”. The app is organically growing using the methodology of having the core and extensions.
Family sharing? I never really looked into that. I had maybe two requests over the years. It’s just a different kind of user base.
Who's really got skin in the game? Perhaps the author who spent countless hours pushing the project along all those years, he took all the risks and uncertainties. Yes, all contributions did help but being a humble contributor I wouldn't ask for any kind of eternal obligation. Otherwise what kind of help is that? If one wants to give, they just give, full stop. Why not stick to free will? Notice the word free.
If you feel this way you should never open source your work. Licences like the GPL as well as licences like BSD/MIT explicitly allow for forks like this.
In other words, Swift is extremely PRACTICAL – meaning create, deploy and earn living – and is squarely focused on people who need that. Naturally, not everybody will resonate with its core mission statement.