Yes, But an iOS app requires a helluva lot more than just the Swift language. For example, Metal has zero support so you have to use ft=cpp and disable lsp diagnostics. And you can completely forget Xcode’s wonderful Metal debugger entirely.
Otherwise swift works just like any other clang/llvm project and the tooling is basically the same.
Yes but most people are not dropping down to Metal support unless they're doing custom effects or developing a game engine. Most apps could be developed outside of Xcode just fine.
Sometimes people add to the discussion by sharing esoteric knowledge because the uncommon aberrations are interesting.
That aside, there was a larger point I was making that was lost in the forest because you poking at a tree. iOS apps are more than Swift. Metal was one example, there are plenty of other tooling components that absolutely suck to use in vim, or just missing support entirely. Bundle management, plist files, custom build phases, code signing, asset previews, canvas previews, interface builder, profiling, and unit testing UI is a bunch of stuff that has nothing to do with swift, sucks in vim, and integral to application development.
If you're okay with old, battle-tested, cheap (and about 2-3 generations back in terms of performance)…
Any ath10k card is great. They support up to 802.11ac, cost about $10 (e.g. amazon.com/dp/B07HDXP9R4), and can run AP in either the 2.4 GHz or 5 GHz bands.
The firmware and driver are very stable and they in terms of regulatory constraints they defer entirely to the Linux kernel (which means you can use https://github.com/singe/wifi-frequency-hacker or similar for frequency hacking).
I don't have much personal experience with ath11k (802.11ax) or ath12k (802.11be), but I've heard good things about them generally.
For use in a real, practical access point, you want to avoid Intel cards. Intel's firmware completely locks down the ability to run a 5 GHz AP. For whatever reason, Intel takes a maddeningly conservative view of regulatory restrictions. They clearly don't want their cards to be used in APs. On the other hand, Intel's cards have a nice feature that they support dual-channel operation with a single radio (e.g. `iw list` shows `channels <= 2`), which is extremely handy for running a quick-and-dirty 2.4 GHz access point while staying connected to a WiFi network.
Which bands and capabilities did you have in mind? For a basic 2.4 GHz, almost anything at this point. Intel and some iteris chipsets are well supported.
mt7996 is good for wifi 7. You can also check the suggested hardware list on the kismet project for good recommendations for older bands and protocol versions
> > Intel and some iteris chipsets are well supported.
> Intel chipsets categorically do not support AP mode
This is not true.
Intel chipsets do support AP mode; what they don't support is 5 GHz AP.
You wouldn't want to run a 2.4-GHz-only router for any kind of real-world long-term use, but if you just want to start a quick-and-dirty 2.4 GHz AP for testing/hacking/reverse-engineering, Intel chipsets are very good for this because they have out-of-the-box support for channel-hopping to support simultaneous client+AP operation.
I have had good luck with intel in the past but it was only a very specific version. Don’t recall the exact specifics as it was a little while ago now.
Supersampling the entire framebuffer is a bad way to anti-alias fonts. Especially since your font rendering is almost certainly doing grayscale anti-aliasing already, which is going to look better than 2x supersampling alone. And supersampling will not do subpixel rendering.
You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.
reply