The approach I took for a recent project was to generate raster tiles for 0-7 zoom levels on the server. This is done in the data pipeline when new data becomes available. I then load the dataset into memory on the tile server and any requests for zoom 8 and above will generate tiles on the fly and cache them for other requests.
Its worked out very well so far, but I'm working with time series that adds a new set of data every 5 minutes so I need the "on the fly" approach. After some heavy optimization it's become quite fast and often the generated tiles are returned before the base map layer is.
The upside is that it works with any map system that supports raster tiles, so any platform really.
I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine.
Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.
GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.
I still rely on GDNative for really performance critical systems though.
I too am in my late 30s and I've been writing Swift for 7 years now and the language itself is not buggy, at least anymore.
SwiftUI has it's issues and one is platform support. If you want to support anything before iOS 13 (even that has limited support) then you are out of luck. The only SwiftUI I have shipped is for WidgetKit and WatchOS, both being somewhat forced upon you.
While it can be cumbersome to do simple things in SwiftUI that were easy to do in UIKit, I haven't found too many bugs. Most issues I have run into are on the Xcode side.
If you work with any Apple platform it is worth pursuing. If you want to just learn and use Swift it does have decent support on Linux thanks to being able to bind with C libraries. Windows support is there, but is very much in its infancy.
Could always use some help. It's still in it's infancy right now, very much a PoC to see if it was worth attempting. Once it gets to a good enough state I will make the repo public and let you know. Props to
Nice job embedding Python in Swift. I haven't done Python, but Wren and Gravity were pretty challenging to get working right. I was going to use a scripting layer for the UI, but eventually came up with a solution that allows for Swift to be used. I sort of mimic the system Apple uses for Playgrounds/Live Preview in Xcode.
I don't have any write-ups from myself. I was planning on eventually posting something, I have a lot of notes to sort through.
You can find some info by searching, there has been a few attempts to get it running on Android. Also just searching around github will net some other attempts.
The foundation dependency is the biggest problem. You can check out https://github.com/apple/swift-corelibs-foundation which gets rid of the objc runtime dependency for other platforms, though you will find yourself writing implementations for each eventually.
I would say if you are going to stay with just Android/iOS to look into maybe moving to Kotlin or C for your common layer and then call it from Swift. Kotlin multi-platform also has been improving recently.
I've actually been developing my own UI library backed by SDL. It currently uses a DSL-like system similar to SwiftUI. I just spent some late nights working on a "hot-reloading" system, though it only works on Mac/Linux currently.
In theory any C based UI libs that support those platforms should work as long as they can be called from Swift.
I don't have a college degree at all. I went from a movie theater projectionist making minimum wage (8 years), to tech support(2 years), to customer service/qa at a startup(1 year), to an iOS developer(5 years), to now being a lead iOS developer at an established tech company. I don't particularly want to be an iOS developer, but it's the path that got me to where I am at and it pays very well. Not once during my last interview cycle (10 different companies) did anyone ask about a degree.
I think the grind and knowledge gained in multiple sectors was worth it, but it was a long road. I've been programming on and off my whole life so I think it really depends on the person, but not having any degree it is doable. Would I do it differently after looking back? Absolutely, but I doubt I would get a CS degree.
Moral of the story, if you want it bad enough and go out there and make it happen, you can find a place in this industry with a high school education. Just demonstrate knowledge and keep on learning.