Got bitten by this issue, but it’s very unlikely you’ll run into the problem unless you have a setup just like me.
It relates to this change in how DropBox works with Sonoma. Specifically:
Packages now behave like regular files instead of directories. * New macOS packages appear as regular files, but are actually bundles that contain other file types within.
- Examples of macOS packages include .pages, .numbers, and .key.
- This new format will have the same functionality as previous package files.
- Existing packages will be updated to the new format the next time they are changed and synced.
- New macOS packages can only be accessed on devices running Dropbox for macOS on File Provider.
In my case, I had 2 machines, both with Sonoma, but one with the “new” Dropbox and one with the “old” Dropbox. I can’t update the machine with the “old” Dropbox as I have my dropbox files on an external drive. (And I don’t want to change that)
Anyway, what seems to happen is that DB messes up the /Contents/Frameworks folder in a built app, confusing the XojoFramework.framework file (which is a bundle) for a folder, and not copying it properly.
The workaround is to compress the .app into a .zip on the source computer, then open it on the other computer.
So, just a heads up if you happen to be using DB and moving .apps from one computer to another…
1 Like
FYI. Frameworks should always be a bundle and NOT a file.
In the past DropBox would do things like replace Symbolic Links with the resolved file, while this causes no damage to the resulting application, it causes increased file size, especially as 88% of the Xojo framework is code that you don’t actually need.
In the early days, App Wrapper was unable to process applications in DropBox, due to DropBox doing things while App Wrapper was working on the files. This is why App Wrapper 4, duplicates the app to a temporary location, does it’s business and then replaces the original.
How does MacOS tell the difference between a folder and a bundle (DB seems to call them a “package”)
AFAIK; Filename extension and UTTypes. You can create your own, albeit I’m not sure if by default Xojo allows you to do so.
DropBox calling them packages is technically correct, because a Bundle is a package, but a package might not be a bundle.
- Packages are folders that look, smell and operate like a file.
- A Bundle is package that conforms to the CFBundle structure, often used for executable code.
- An Application Bundle is a bundle that conforms to the “Application Bundle” structure.
- Frameworks are bundles that confirm to the Framework structure.
- Document Packages are cool, because they conform to the Package UTType, which makes it much easier to store multiple and structured data in (what the customer sees as) one single file.
NSURL has resource keys for identifying if a folder is bundle or a package. You can also verify by using the UTType.conforms( to: ) function.
Neither of which are exposed by Xojo, so you’ll need declares or a plugin, or I guess you could do what I assume DB did, if it’s a folder with a file name extension, assume a package.
1 Like
It wouldn’t work with me, though. I often use “extensions” with folders (more precisely, periods in the name, which equals an extension).
Just pointing out what you could do if you’re using a language that doesn’t natively expose the API required to properly verify a file system item. Believe me, I’m not saying you should do it this way, you should always use the UTType.conforms(to:) API as that 's the API Apple recommends for validating file type conformity.
But you know, Xojo…