3 ms·

I agree with most of what you've said here, except: - Code signing. It's incredibly frustrating as a developer to try and codesign an application to pass gatek

I agree with most of what you've said here, except: - Code signing. It's incredibly frustrating as a developer to try and codesign an application to pass gatekeeper, requiring multiple steps with very little information as to what's _actually_ going on or going wrong in the middle of it, including uploading your entire bundle to Apple and waiting an arbitrary amount of time for them to notarize it. > It's very weak that the OS has no way to keep apps up to date except via the store, which then introduces tons of other problems. Sparkle does a great job of patching up this gap, but it should really be a core OS service in this day and age. App Store _is_ the solution and a core OS service. You may not like the limitations that implies, but it is the OS level solution for keeping apps up to date. > And the lack of any high level GCd/managed language for their platform continues to be a major weakness. I think swift fits this gap nicely, no? It's not technically GC'ed, but it is refcounted, which for end user case achieves the goal of "ignore memory mangement for small tasks" I like this blog post [0] which shows a desktop app in 11 lines of code. [0[ https://www.amimetic.co.uk/blog/swiftui-for-small-internal-desktop-app-tools/ https://www.amimetic.co.uk/blog/swiftui-for-small-internal-d...

pjmlp 4y ago
Code signing is coming for Win32 as well, as announced at BlueHat IL 2023.
- yyyk 4y ago
  I searched and found the slide: https://msrndcdn360.blob.core.windows.net/bluehat/bluehatil/2023/docs/DAY2/dwizzzle_bluehatil_slides.pdf https://msrndcdn360.blob.core.windows.net/bluehat/bluehatil/... (Pages 20-22). Oh dear.
mike_hearn 4y ago
A core OS service in my books is an API that can be used by any app, can be adopted in a backwards compatible way and which is used by the in-house apps too. The App Store isn't an API or service, it can't be used by every app and the built-in macOS apps aren't necessarily store apps. Yes, it's Apple's strategy but I maintain that from a tech perspective it's a very weak one. Cryptography DX is always terrible on every platform, I don't know why, it seems to be an unwritten rule that crypto tools must have as many sharp edges as possible. But as far as these things go, Apple's infrastructure actually is effective and flexible. Notarization got a lot faster lately and is certainly way better for both devs and end users than client side virus scanners. Swift is a good upgrade, but not exactly a high level managed language. Most of those languages have very fast or non-existent compile times as well as GC, they tend to be simple-ish, perhaps they have optional types. The Swift DX is quite different to a C# or a Java for example.
- maccard 4y ago
  > Yes, it's Apple's strategy but I maintain that from a tech perspective it's a very weak one. Gotcha. I disagree, but I think that's ok. > Cryptography DX is always terrible on every platform, I don't know why, Let's encrypt is a pretty good example of how simple it can be. The experience of codesigning + notarisation as a developer is poor. If you want to use the GUI and are working from xcode templates, it's fine, but apart from that, you're into glueing together forum posts running binaries and tools with no logs that report success with arbitrary delays that work on your local device but not on other devices. > Swift is a good upgrade, but not exactly a high level managed language. Most of those languages have very fast or non-existent compile times as well as GC, they tend to be simple-ish, perhaps they have optional types. The Swift DX is quite different to a C# or a Java for example. Swift has ARC, fast compile times, and a _very_ high level interface to the underlying API's. I think it's very comparable to C# on windows for many, many things.
- ElFitz 4y ago
  Personally, my biggest gripe with the Swift DX, or anything DX related on macOS, actually is with Xcode.
  - maccard 4y ago
    AppCode or bust.
    - ElFitz 4y ago
      Sadly it doesn’t enable you to totally bypass Xcode. And JetBrains is sunsetting it: https://blog.jetbrains.com/appcode/2022/12/appcode-2022-3-release-and-end-of-sales-and-support/ https://blog.jetbrains.com/appcode/2022/12/appcode-2022-3-re...
kitsunesoba 4y ago
Automatic reference counting is very well streamlined into Swift. Even in more substantial projects in most code I'm not putting much active thought into memory management at all with it. The main area where some extra attention is required is in closures, and there in most cases the main thing is to not strongly reference self which is easy to avoid. As for the compile times mentioned by the sibling comment, they're pretty tiny for small utility things, especially incremental builds. On more recent hardware (M1, Ryzen 5000, etc) I find they're reasonable even for moderately sized projects… on M1 Pro a complex iOS app with somewhere in the ballpark of 30 different screens can be clean-built in under a minute with incremental builds usually under 3s which seems plenty reasonable to me.

pjmlp 4y ago

Code signing is coming for Win32 as well, as announced at BlueHat IL 2023.

yyyk 4y ago
I searched and found the slide: https://msrndcdn360.blob.core.windows.net/bluehat/bluehatil/2023/docs/DAY2/dwizzzle_bluehatil_slides.pdf https://msrndcdn360.blob.core.windows.net/bluehat/bluehatil/... (Pages 20-22). Oh dear.

mike_hearn 4y ago

A core OS service in my books is an API that can be used by any app, can be adopted in a backwards compatible way and which is used by the in-house apps too. The App Store isn't an API or service, it can't be used by every app and the built-in macOS apps aren't necessarily store apps. Yes, it's Apple's strategy but I maintain that from a tech perspective it's a very weak one. Cryptography DX is always terrible on every platform, I don't know why, it seems to be an unwritten rule that crypto tools must have as many sharp edges as possible. But as far as these things go, Apple's infrastructure actually is effective and flexible. Notarization got a lot faster lately and is certainly way better for both devs and end users than client side virus scanners. Swift is a good upgrade, but not exactly a high level managed language. Most of those languages have very fast or non-existent compile times as well as GC, they tend to be simple-ish, perhaps they have optional types. The Swift DX is quite different to a C# or a Java for example.

maccard 4y ago
> Yes, it's Apple's strategy but I maintain that from a tech perspective it's a very weak one. Gotcha. I disagree, but I think that's ok. > Cryptography DX is always terrible on every platform, I don't know why, Let's encrypt is a pretty good example of how simple it can be. The experience of codesigning + notarisation as a developer is poor. If you want to use the GUI and are working from xcode templates, it's fine, but apart from that, you're into glueing together forum posts running binaries and tools with no logs that report success with arbitrary delays that work on your local device but not on other devices. > Swift is a good upgrade, but not exactly a high level managed language. Most of those languages have very fast or non-existent compile times as well as GC, they tend to be simple-ish, perhaps they have optional types. The Swift DX is quite different to a C# or a Java for example. Swift has ARC, fast compile times, and a _very_ high level interface to the underlying API's. I think it's very comparable to C# on windows for many, many things.
ElFitz 4y ago
Personally, my biggest gripe with the Swift DX, or anything DX related on macOS, actually is with Xcode.
- maccard 4y ago
  AppCode or bust.
  - ElFitz 4y ago
    Sadly it doesn’t enable you to totally bypass Xcode. And JetBrains is sunsetting it: https://blog.jetbrains.com/appcode/2022/12/appcode-2022-3-release-and-end-of-sales-and-support/ https://blog.jetbrains.com/appcode/2022/12/appcode-2022-3-re...

kitsunesoba 4y ago

Automatic reference counting is very well streamlined into Swift. Even in more substantial projects in most code I'm not putting much active thought into memory management at all with it. The main area where some extra attention is required is in closures, and there in most cases the main thing is to not strongly reference self which is easy to avoid. As for the compile times mentioned by the sibling comment, they're pretty tiny for small utility things, especially incremental builds. On more recent hardware (M1, Ryzen 5000, etc) I find they're reasonable even for moderately sized projects… on M1 Pro a complex iOS app with somewhere in the ballpark of 30 different screens can be clean-built in under a minute with incremental builds usually under 3s which seems plenty reasonable to me.