• Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership.
• Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems.
• Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is.
• There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner.
• Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code.
• Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones.
.app packages are merely the binary with assets and a bunch of metadata for code signing, entitlements, icons and locales. If you "Show Package Contents" there's not much to them.
• Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership.
• Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems.
• Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is.
• There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner.
• Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code.
• Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones.
[1] https://hydraulic.dev/ (disclosure: my company)