I'm deploying an Electron app with Squirrel on the backend to do updates. The Windows deployment works just fine, updating from a .nupkg at this sample path:
https://host/update/win32/1.0.1/RELEASES
However, the Mac version (which I'm supplying a .zip file to as per the docs) does not seem to work. I've run across some contradictory information on the pathing (and have tried them all, plus a great many variations in case there were typos in the docs), but the very latest info I could find is what I'm using now:
https://host/update/darwin_x64/1.0.1
What path should I be using for OS X? Is there perhaps something about the .zip file that Electron-builder (with the Squirrel module) is creating that might be causing a problem?
Your question is tagged as electron-builder. electron-builder supports server-less and simple auto-update.
My code signing environment variables were not getting properly set in my OS X build script, so code signing was not happening. In order for OS X apps to update via Squirrel, both the new and the old versions MUST be signed.
Related
The situation is that I have three developers working on a project. One developer is on Mac OS X and the other two are on Windows 10 Pro machines. My project consists of .NET Core 3.1 SDK and utilizes docker support to run. It was created in Windows initially so the docker-compose.override.yml file has the following lines of code under Volumes:
- ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
- ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
This works perfectly on Windows environments. However on the Mac OS X side the developer constantly has to update the config of docker-compose.override.yml volumn links to look like the following:
- ~/.microsoft/usersecrets:/root/.microsoft/usersecrets:ro
- ~/.aspnet/https:/root/.aspnet/https:ro
Has anyone ever dealt with a situation like this? What did you do to overcome it besides asking the developer to BootCamp or Virtualize Windows 10 on their Mac?
Update:
I just tried to update the docker-compose.override.yml file to accept the Mac OS X volume lines. I ran it on my Windows machine as well as my Mac OS X machine. It seemed to work properly. I have reached out to my developers to test it out on their machines to see if it will work. Once I get their responses I will update this question.
Update #2:
Looks like my developers on both platforms are able to run the docker-compose project using the Mac OS X Volume lines.
A few options come to mind:
Have the Windows devs use WSL so the paths match Mac OS X
Declare environment variables for each path and reference those in the config
Have an extra compose file that contains the volume declarations but isn't checked into source control so it doesn't get overwritten
I've not done any of these so can't say if there's any pitfalls, but the 2nd and 3rd approaches I have used in the past on non-Docker projects where this kind of scenario occurs.
I'm running Xcode 8.1 on Sierra 10.12.2 using Swift 3.0. I'm trying to find the sqlite database the Core Data writes to when it is serializes data. I've found several other questions here on the same subject. Since the location seems to move with every major release, they are out of data. Also, they address iOS simulators. Presumably,I'm not using one when running Mac OS code on Mac OS.I tried doing a find on *.sqlite. I got a lot of matches. None one them looked like they were for my project.
Currently, and with the toolchain you describe, the template is set to:
~/Library/Application Support/com.apple.toolsQA.CocoaApp_CD/swift_cd.storedata
You can edit this in AppDelegate.swift. See the lazily instantiated var: applicationDocumentsDirectory.
I have an application in the Mac App Store. I'm trying to support users going back to Snow Leopard but this is becoming increasingly difficult.
Recently I've hit a roadblock due to the iTunesLibrary.framework, this framework must be linked to the main executable and yet doing so will always trigger a crash on load when running in Snow Leopard.
To workaround this problem, I want to compile a version of my app that doesn't use features and frameworks from newer versions of OSX. The problem is, how can I launch the compatibility build automatically?
I'm considering trying to make the main executable point to a shell script, but I don't really like that idea. I've also thought of the main executable being a helper that simply launches the full app and then exits. I expect this would work, but I worry about it getting approved by Apple. Finally, I'm wondering if the app bundle format itself can support this kind of setup, maybe via an advanced used of CFBundleExecutable that I'm unaware of.
Has anyone been down this road, what would you suggest?
Try weak linking the frameworks, more information about Weak Linking and Apple Frameworks here. Then also check in your code for the OS version or - (BOOL)respondsToSelector:(SEL)aSelector of any NSObject to determine what you can call and what not.
To have Snow Leopard as Base SDK you'll need an old Xcode and will have troubles submitting to Mac App Store.
My app needs to run on 10.4 or later. If I launch it on 10.3 it just fails to launch or crashes.
How do you tactfully enforce minimum system requirements? Can you customize the message it shows?
Add a key to your applications Info.plist, specifying LSMinimumSystemVersion as 10.4.X for whatever X you need as a minor version. For more, see Apple's documentation.
I have not used either of these techniques/advice, just passing along the information I have gathered.
You might try something like the SystemVersionCheck “shim” executable to provide a working OS version check for versions that do not honor LSMinimumSystemVersion (e.g. 10.3).
The pre-compiled executable is PPC-only. You might need to rebuild it to support PPC and Intel machines so that it works with 10.3, but also so that 10.6 users are not prompted to needlessly install Rosetta. I found a blog entry that has a hint on how to setup the PPC build to target 10.3 and the Intel build to target 10.4u (it was written about 10.5 and Xcode 3.0 though—do the latest versions of Xcode even include the 10.3 SDK?).
If you experience a crash after adding the LSMinimumSystemVersion key to your app's plist manually, then this is due to the Finder not recognizing the changed state of the app properly. Either restart the Finder (e.g. log out) or duplicate the app in the Finder. The copy will then behave correctly.
I have an exe setup file. I want to make it compatible with Mac OS. Is there is any way through which we can convert an EXE to DMG, APP or a Jar?
No, you cant, you need to recompile the application for the target platform.
Nope*.
Moreover, if the contained software is compiled for Windows, it won't work on Mac.
If may work only if it is script-based (like in ruby, python, etc.). But usually, you'll have a proper Mac installation package when it is compatible.
**Exception*: some EXE are extractible archives, but it won't change the incompatibility if it is compiled for Windows.
The simple answer is to install software on a Macintosh OS you must recompile it down to a .dmg file. I jumped on Google and this article Creating a Mac OS X App from a Jar File was the second choice. The default Mac OS Java version was 1.5 for Leopard. Target 1.4+ and you should cover systems from at least Leopard and upwards.
As an aside, this tutorial was recently updated for Snow Leopard and covers the same stuff. Best of luck in getting it ported.
There are different distribution for Mac with have java6 and below version, for java 7 and 8 you need to make another app to run and compatible with
I did it on my way:
Create exe/ setup for your jar.
follow the link ---> winebottler.kronenberg.org
download winebottler(GUI based tool) for your mac type and simply follow this link below
https://www.youtube.com/watch?v=imPGlqEuYBk
No extra burden for you to how.
Note: This will pack your setup in app but app size will increase.