I see these CodeResources folders in some of the system Mac apps and some third party apps. What are they?
The file is a result of code signing; it keeps track of the digital signatures of various application resources (images, etc.).
Related
I am a visual artist, rather than a developer and I developing a Mac app using Kotobee (Kotobee.com) instead of Xcode.
Kotobee is an interactive eBook authoring tool, and it can export native Mac or Windows apps, with a full log-in mechanism and with the native .app extension. This was the perfect tool for someone like me who is not a Mac developer (but visual artist with web development skills)
THE PROBLEM:
the exported app gets the “From Unidentified Developer” warning.
QUESTIONS:
Is it possible to sign an app that was compiled by a 3rd party compiler (Kotobee), and not Xcode?
If it’s possible, what is approximately the process?
Is it an issue if the final app is encrypted by Kotobee? It’s possible to export non-encrypted version, but I really need encryption as the app is full of high value interactive 360 visuals.
Thanks!
I tried to read about code signing, but they all start with Xcode.. ..but I am using Kotobee to export the .app software. It's confusing what I can and what I cannot do.
I am new to macOS app development. I have knowledge on Windows App development. I have a server application which can be installed offline. For communicating there is a client library which is a .dylib. I want to distribute the .dylib using macOS App Store so that third party application can consume the library.
How to install the .dylib and headers to a location from macOS App Store as a installer?
You cannot distribute dynamic libraries and header files through the App Store. It's for applications only.
Instead, have a look at other means of distributing libraries such as CocoaPods, XCFrameworks etc.
Mac App Store is quite restrictive when it comes to installers. Usually you would distribute an .app that can be run directly and the app then installs more things if needed.
What kind of apps would consume your library? Why not provide a "Framework Bundle"?
This is the typical way to distribute libraries within macOS
How to install the .dylib and headers to a location from macOS App Store as a installer?
You don't. I'm afraid the App Store is not a package manager.
While you can put libraries, CLI binaries and other resources inside a GUI app bundle, you cannot distribute anything other than a GUI app bundle via the App Store. And neither could 3rd parties mark their app as "depending" on your app. And if they linked against a dylib outside of their app path, then it's highly likely that the app would get rejected in review because it would be found to not work. Again, it's not a package manager.
All apps on the App Store are required to be self-contained, so the way Apple wants developers to handle dependencies is by bundling a separate copy.
Thus, the only "supported" way to distribute your library in a way that can be used on the App Store is to make it available for download on your website, and then have each developer bundle a copy of it when they ship their app.
Of course you could opt for other (or additional) channels like brew, which are actual package managers, but that won't help with anything on the App Store.
I have added desktop extension to my UWP app that gives some extra functionality if it runs on Windows 10 desktop platforms. But for other platforms it won't be used. Hence I want to make sure that the desktop extension isn't installed on other platforms thereby saving users some disk space. I have looked into app extension but it won't be viable for my use cases since the UWP app and desktop component communicate via named pipes and memory mapped files. Is there any other way I can control the installation of desktop component depending upon the platform it is being installed??
Update 1
From researching further I have found that this should be possible with optional packages/related sets, to be accurate related sets for my scenario. The examples provided in docs only show scenarios for packaging uwp apps as related sets and no example for packaging win32 apps as related sets was given. Is there any way to package a win32 application as related sets??
Is it possible to create an OS X Yosemite Today Widget without a host app, like the builtin Weather, Stocks and World Clock apps?
You can not do that simply because your executable is still running in the companion app rather in the extension. It means that codes are actually belonged to the companion app. So, you must have your companion app.
Info from the official documentation:
An app extension is different from an app. Although you must use an
app to contain and deliver your extensions, each extension is a
separate binary that runs independent of the app used to deliver it.
For a new desktop app project I'm researching if it's feasible to create a cross-platform implementation instead of native Windows and OS X apps. Chrome Apps seemed promising, but after browsing through the Chrome APIs there are some things I didn't see that I'll need in my app:
Notifications on changes to files in the local filesystem. (File System Events API on OS X, FileSystemWatcher on Windows.) At first I thought the syncFileSystem API might help with this, but it's apparently only for syncing with Google Drive, which is not what I need. I guess I could workaround this by scanning the directories I'm watching on a timer, but that won't perform well if there are a lot of directories and/or files.
Ability to add context menus in Windows shell and OS X Finder, as I would be able to with a Windows shell extension or OS X Finder plugin.
Ideally (although probably not a hard requirement) get the app into the Windows System Tray / OS X Menu Bar (NSStatusItem).
Can anyone confirm whether it's possible to access this functionality with a Chrome App? If not, can you recommend an alternative cross-platform tool for building an app with these features?
All of the listed features have bugs logged, but no real progress at the moment:
Watch: https://code.google.com/p/chromium/issues/detail?id=148873
File manager integration: https://code.google.com/p/chromium/issues/detail?id=130455
Sys tray: https://code.google.com/p/chromium/issues/detail?id=142450
The first of these to be made available will probably be file manager integration, which is being worked on now.
We'd love to improve watching but it is a significant task to support this on all operating systems and we don't have anyone working on it now.
Sys tray support is something we have no plans to release soon as we're not sure how we want to support this on ChromeOS.
I could not find anything close to the items you have mentioned. I did however find this product: node-webkit that likely would get you onto both your target platforms, use the same basic code-base (HTML5/CSS/JS) and allow some possible per-OS customization. There is even a 'watch' project under NPM that covers your first bullet point. Check node-webkit/wiki for notes on how to add C/C++ extensions to their node build (under using-node-modules.) Project seems active and appears to be backed by Intel (they re-built their XDK product on it to do cross platform.)