A couple of our customers have expressed interest in running our desktop application on a Macintosh. Up until now, each of our schools have been able to run our application from a Windows computer. We haven’t really tested running on a Macintosh. I know just loading up is fine and logging in is fine. It all appears to be normal. My question is, is there any major programming differences between Windows and Macintosh? I want to start testing for Macintosh, so any ideas on what to pay attention to would be helpful. TIA
Well, I wonder how you’re supporting Macintosh because that’s long since dead. 
macOS applications must be code signed and notarized, so you’ll be looking at a new $99/yr cost to distribute for macOS.
macOS has significantly more strict security. You cannot assume access to folders like SpecialFolder.Documents or SpecialFolder.Desktop you must always ask the user for permission through an Open or Save dialog. Also in line with security, macOS requires URLConnection use https.
I’m sure there are other platform specifics to consider that I’m neglecting in this post, but the biggest takeaway should be: Security
Think carefully about what your functions do and if something could be misused to write malware it’s probably blocked by macOS security.
1 Like
It’s fine if we need to pay to get code signed to run on Mac. Ive been testing on my MacBook Pro and I can update and everything with no problem outside of the App Store. So far, I haven’t run into any security issues with updating and downloading. Our website is set up with certificates so the https isn’t a problem. But thank you for mentioning this. I will pay attention to what permissions its asking for so each of our schools techs can set it up for the user.
That’s only the case if your app is sandboxed (though I think that’s a requirement if you’re going to distribute on the app store). If it isn’t the system will just automatically prompt the user for permission to access those folders.
For this one, you can still access http addresses by putting an NSAppTransportSecurity key in the plist.
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
But yeah, you’re right that there are more steps involved due to the increased security.
I just wrote a sound file player for my wife.
Tunes from all over the computer can be added to the listbox and played.
The app can save different lists (text file with the name and Finder path of each sound) to reload and play later.
Both Sandboxed and non-Sandboxed versions of the app work the same UNTIL the app is quit and restarted. After that the Sandboxed version allows playlists to load, but denies access to play the files. I think this is related to the Open File Dialog that Tim mentioned.
Even so, the App will still show the file in the Finder.
Var s As New Shell
Var st1 As CString =FullPath(tst)
st1 = "open -R "+Chr(34)+st1+Chr(34) 'open -R /path/to/your/filename.txt
s.Execute(st1)
Xojo has some entitlements settings to allow Sandboxed apps access to some folders.
I can copy a non-Sandboxed copy of the app to computers on the local network and it will run without issues. The same goes for copying from a thumb drive. I think distributing apps over the internet is when security starts to kick in, and distributing via the App Store is when you’ll see even greater security restrictions.
As everybody in the thread has noted, accessing the file system is a big difference. As far as the abstract Xojo classes are concerned (things like Dictionary, String, etc.) you will find them to be very cross-platform reliable.
If you are using any Declares, those are inherently platform-specific and will need to be figured out.
UI classes are mostly reliable between Desktop platforms. I’d pay attention to differences in MenuItem and Listbox, as they sometimes show some differences; any fancy window tricks you might be using; and especially transparency, as that imaging technique is very different between platforms and tends to catch people up.
Finally – once you get your app up and running, consider whether the UI aesthetic is right for the Mac. Are you using an appropriate color scheme for any custom drawing? Are typical UI elements in the expected place, and do they work as anticipated? Does your app store its files in the recommended locations? Does your app look and feel like other Mac apps? Xojo does a good job of handling the basics but Mac users are frankly pretty sensitive to an app that feels out of place on that platform. If you’re not a Mac user, consider asking a Mac-specific user to take your app for a spin and give their honest feedback. Your Mac users will thank you. 
Keep in mind that running locally is not the same as downloading onto another Mac. Apple specifically makes it harder to just copy an app from one Mac to another and even harder if it’s downloaded from the internet.
As Tim said, make sure you’re signing the app and notarizing.
I can’t comment on any of the security stuff because I don’t use the App Store, sandboxing, or any of that.
In general Xojo prefers MacOS - everything works more in accordance with the docs, the UI is more WYSIWYG, and everything is faster. My problem is that I do all my development on MacOS but pretty much all my users are on Win and I am often negligent in testing on Win so quirks come back and bite me. Had one today involving timing of Window.Open vs controls opening - supposedly all controls have finished opening before Window.Open fires, but it seems that’s not always the case under Windows.
2 Likes
You need to use security scoped bookmarks. Think of like FolderItem.SaveInfo that retains permission to access the file. I believe Kem Tekinay has some code somewhere for this. I’ve got a class I use, but it’s not a ready-to-use component. Still, you could find the declares necessary in it. Beacon/Project/Modules/FrameworkExtensions/BookmarkedFolderItem.xojo_code at master · thommcgrath/Beacon · GitHub
2 Likes
One special mention about “OK” and “Cancel” buttons, which are usually swapped (“OK”/default button at right on Mac, but at left on Windows).
Thanks for the link. An Apple fellow just pointed me to security scoped bookmarks too. I’m going to tuck that away for a possible future version. Apple security looks to be a vocation of its own.
If knowing focus on a control is important, compare each of the controls you will be using. Some controls do not get focus on MacOS that do on Windows. I’m not aware of any the other way around. But checking each one will give what to look for.
Thanks everyone for taking time to respond. The suggestions were very helpful.
I’ve been running into the same problem. I have to Var w As theWindow, do initialization stuff especially the controls, then .Show. Seems to work then but was stumping me before I got a hold of the events order. Apparently the window Open event seems to run last so some control initialization gets lost.
1 Like
These controls do not accept text.
BUT: you can change that macOS setting.
You would have to change the setting on each computer it runs on, or don’t depend on control focus.
The menu bar is always at the top of the screen, not the Window. But each window can still show its own selection of menu items. From Xojo’s point of view it works the same way, except for the placement.
if your app has a Settings menu item make sure its parent class is DesktopPreferencesMenuItem and Xojo will move it too the application menu for macOS builds
Hello
Tim we can freely copy the applications for mac without going through appleStore!
I have been developing mac and pc applications since the 90s.
I have always seen problems with PCs, we used to say that PCs were unfinished machines.
Jeffrery difficult to tell you the differences between Mac and PC
I advise you to make a Mac application, run it on a Mac and note the non-functioning points to make it an application for Mac and PC at the same time prepare it to switch to a UNIX system.
Hello Jeffery
I also do Windows, but i played around with mac some years ago. One thing that I discovered back then was that mac and Windows have different event handling order. This can cause som tricky issues. I recommend to do a simple test app loggning the event order and compare the results from mac and Windows.
/HÅkan
This might be true, and the answer is to structure your code so it does not rely on any particular event order.
3 Likes
Hi Jeffery,
I haven’t seen this specifically mentioned, so I’ll throw it out there. If the application is writing and/or reading files, especially text files, it might be a good idea to pay close attention to those operations. Windows and MacOS have different End of Line characters. For example Mac uses just a LF where windows uses CRLF. Depending on how you are working with these files, you may need to account for that in your code using TargetWindows and TargetMacOS with routines in each specific to the OS.
1 Like