Lazarus
Programming => Operating Systems => macOS / Mac OS X => Topic started by: stem on December 31, 2018, 04:11:06 pm
-
Hi,
I'm developing an application that runs as well as on Linux as on Windows. Everything works fine on both operating systems.
Now I'm thinking about supporting MacOS. As I'm completely new to Mac(OS), I've done some reading in the forum about the different widgetsets and about the installation of Lazarus.
Did I unterstand correctly that Cocoa is not fully supported with Lazarus and not as stable as the other widgetsets, although Cocoa is the widgetset one should focus in the future? Is it a "good" idea to do coding for MacOS with Lazarus and not with XCode? (I've read that there are many users of MacOS, but not many developers with Lazarus.)
So the final question: Is it "worth" having an eye on MacOS + Lazarus and thinking about buying hardware or will the "Lazarus experience" not be as good as with Linux and Windows? ;)
Additional question: Assuming I create an application with Lazarus and the latest MacOS 10.14 Mojave, will it run on other versions of MacOS? If yes, on which? Thanx.
Thanx alot and a happy new year
Stem
-
Assuming I create an application with Lazarus and the latest MacOS 10.14 Mojave, will it run on other versions of MacOS? If yes, on which? Thanx.
if you link the app for the compatibility with the previous versions of macOS, then you can go as low as 10.6 for Cocoa.
and 10.4 for Carbon.
-
This really is the chicken or egg question.
Lazarus depends on users - who report issues - to become (or keep being) a good environment.
This is true on all platforms. On Windows and Linux there are plenty of people, and problems are discovered, and the developers (or sometimes users by means of patches) can fix them.
At current there is active development for cocoa. So if you run into issues they may get fixed.
So the final question: Is it "worth" having an eye on MacOS + Lazarus and thinking about buying hardware or will the "Lazarus experience" not be as good as with Linux and Windows? ;)
About the buying, if you go for x-code you have buy it too.
About coming from windows... You probably will scream about the OS differences, even before you download Lazarus. Every mouse action and keyboard usage are totally difference.
That goes to the point, that many of the key-combos that Lazarus uses, are occupied by the MacOs, and you need to use others.
As for comparing the IDE and LCL experience:
There are widget dependent differences, some by design. (same as some things work diff in gtk, compared to win).
Cocoa is much newer. So it is far less tested. But it also is actively worked on right now.
I have no experience of my own how they compare.
But I would say, you will have to expect some pitfalls at the very least.
(while I wrote about debugging speed (below), compiling is slower too)
No idea if it is worth it. (in terms of money spent on the hardware).
------------------
As for comparing debugging:
(one of the topics, and the one on which I can comment)
You have a choice between gdb-based and lldb-based.
gdb based is extremely hard to get working. If you do get it working (and that is a very big IF), then it will (should?) be similar to what you have on windows.
lldb works out of the box. But it will be first released with Lazarus 2.0.
Some beta testers report that it generally works. But once it goes officially released, I am certain there will be a ton of bug reports.
- Debugging with the lldb based debugger is definitely slower than gdb-based on Windows. And that can NOT be fixed.
- lldb based does not (or not fully) support watch-points. And it is unclear yet, if that will improve.
- "step over to cursor" is not implemented. It is a todo. But with low priority
- attach/detach is not implemented. It is a todo. But with low priority
- debugging libraries is not implemented. It is a todo. But with low priority (and unclear how well it will work)
- modifying watches value is not implemented. It is a todo. But with low priority and unclear if possible (though that has severe limits on windows and gtk too)
Probably more. But as I said, many differences will only become clear, when people start using it.
-
This is a lot of simple questions that aren't however simple to be answered.
I personally develop software for the Mac with Lazarus since 2011. It allowed me to migrate old Pascal code (written in the 1990ies with THINK PASCAL) to modern platforms, and this method delivered well-functional professional platform-sensitive apps. However, we have also to admit that Lazarus is less mature on macOS, especially if compared to the Windows version. The last months witnessed considerable improvements with the advent of rather complete Cocoa support and debugging facilities made available again. There is still, however, a quite large amount of work to do.
-
My main computer is a MacBook Pro, I cross compile for Windows and Linux.
Depending on what I'm doing, I usually either compile for Mac-only (Cocoa, as Carbon is EOL) or cross compile for all of them.
Lazarus is incredibly handy for creating Mac applications.
Sure there are some things to keep in mind between platforms, but for the most part things work very well across platforms.
-
Additional question: Assuming I create an application with Lazarus and the latest MacOS 10.14 Mojave
If you want to use Lazarus and MacOS, I would recommend that you buy an used MacBook that runs for example 10.10 Yosemite. The development experience is pretty good there. I am writing a commercial software with this setup.
With 10.14 it is very hard to get the debugger to work, because Apple dropped gdb support and AFAIK Lazarus doesn't support lldb at the moment.
-
With 10.14 it is very hard to get the debugger to work because Apple dropped gdb support and AFAIK Lazarus doesn't support lldb at the moment.
I have Lazarus 2.0 RC3 with lldb debugger running here (see http://forum.lazarus-ide.org/index.php/topic,42869.0.html for instructions). It works quite well, although lldb is slower than GDB.
-
My experience is very directly related to your question. I built an app that compiles from one code base on both Linux and Windows. I wondered about mac, never used one myself. I managed to pick up an old, 2012, Mac Powerbook on ebay for a hundred odd dollars AU$. It had faulty USB ports but otherwise works fine, I run Sierra (10.12).
I was not willing to maintain a separate code base, if it was just a case of "write once, compile anywhere" it was worthwhile. My code has a few easily managed $IFDEFs and I can build both Carbon and Cocoa based versions. The Cocoa one I still class as experimental, it has a few issues. The Carbon one works fine - again, while I have had to adjust the code to accommodate Cocoa, there is no separate inc files specific to one platform.
I think martin_fr is being a bit harsh, gdb can be got going if you follow some laborious but clear enough instructions. lldb works, if its slow, I assume its because I'm using old hardware !
But this approach really means you spend very little time developing on the mac, most work is done on your preferred platform, you will test and, occasionally, debug on the Mac.
You will have to spend time making the Mac specific distribution package, its quite complicated but once setup, just a case of running a few scripts. See the scripts in my project's 'package' directory, its all open source !
Use the fixes_2_0 branch of Lazarus, its Cocoa is heaps better.
In summary, yep, I reckon you should !
-
Hi,
thank you for your answers and a happy new year! :)
Do I understand correctly that
a) I need at least macOS 10.4 for building Carbon apps
(only 32 bit) and at least macOS 10.6 for building Cocoa
apps (only 64 bit)?
b) an app built with an old Mac can run and looks the same
on the most modern Mac?
c) Carbon will be discontinued by Apple in the future?
d) Cocoa support of Lazarus is being worked on heavily
at present, so that future versions of Lazarus will much
better work with Cocoa?
;)
stem
-
a) I need at least macOS 10.4 for building Carbon apps
(only 32 bit) and at least macOS 10.6 for building Cocoa
apps (only 64 bit)?
No, I don't think either is the case. I'd expect, but don't know, you can go back further than 10.4.
b) an app built with an old Mac can run and looks the same
on the most modern Mac?
Yep.
c) Carbon will be discontinued by Apple in the future?
Yes, when you (first ?) startup a 32bit app in the newest version, you get a warning.
d) Cocoa support of Lazarus is being worked on heavily
at present, so that future versions of Lazarus will much
better work with Cocoa?
Probably !
And a happy new year to you too !
Davo
-
About buying hardware: they are grey areas like virtual machines running macOS, or a Hackintosh on existing hardware, or even rented remote desktop access, that might help evaluating the system before purchasing Apple hardware (or Hackintosh hardware).
I do cross-compile to macOS and Linux from Windows and just need the Mac to wrap/sign an App Store compatible bundle & package.
Can't speak much about the LCL, since my app has a custom BGRA based GUI, but the few bugs I encountered were quickly fixed.
The Lazarus IDE was bit struggling the past months (especially on the Mac, I "need" AnchorDocking, which failed the past few weeks), but usable, and debugging using lldb is indeed a good experience (seems to be more responsive than gdb on Windows).
-
Progress of current Cocoa support is amazing. Running hackintosh (Ryzen CPU, NVidia GPU :) ) without any issuses. Little worried about new ARM CPUs for MacOS (if any) and how fast Lazarus team will bring arm support for this platform.
-
If you do not have mac hardware and would like to try, by far the simplest is to run macOS (if it's on non-Apple hardware) using VMware Workstation. There is a slight hack, it's on the web, but works well. You can take snapshots and wind-back if things blow up. Overall a good idea.
As suggested you can build a Hackintosh, but this is significantly more complicated and generally breaks with every OS upgrade. If things blow up you have some difficulty resurrecting the system. Personally, and YMMV, I would not recommend the Hackintosh route.
Further, if you buy an older, cheap (sic) mac/macbook/macmini and can run either parallels or FUSION (mac version of VMWare Workstation) just ensure that you have as much RAM as possible (16GB is good). You can then buy a (relatively) cheap Thunderbolt 2 SSD drive (TB 3 will not play unfortunately) or a USB 3 SSD drive which are both adequate to run VMs at a reasonable speed especially if your main system disk is relatively small. Note if you upgrade later to a system with TB3/USB C the TB 2 drive will work as a standard USB 3 Drive. You also get the Apple connectivity with Drive sharing, iMessages (if you have an iPhone) etc etc...
TL;DR run macOS in a VM
HTH
-
Posting from the future. My answers are timeless, though, I think. :) If your program must have a Mac OS port, e.g. business software for deployment in a company, you should have a very late Mac OSX version running at least for testing. If it's just a case of supporting Mac OSX also, I wouldn't bother unless it's a killer app or game that is, or you think will be, popular.
As for costs, anything that needs XCode requires a yearly fee of $100 to Apple. You will likely also want to distribute over the App Store, because Apple allows perfectly valid installation packages and executables only from the devs they know and themselves, and clients will have to have admin rights and muck around with System Prefs to run them. There's also the cost of the OS itself, which is only free for Mac buyers AFAIK. A quick Google suggest you can't buy OSes separately since 10.8?
If you're making games, a big issue is that Apple has dropped OpenGL support in favor of their own Metal (only), naturally expecting all devs to rewrite their games and engines for Metal. :D
As for development, I have a Mac, and compilation and execution performance is several times faster with the Windows version in a VM on the Mac, than making native applications on the Mac. I don't know why, but Mac GUI components have been rewritten to not be slowed down by the 5K resolution, and maybe Lazarus and Forms don't yet take advantage of that.
I'll leave cross-compilation for more experience devs to answer, but in order for your application to not be seen as an intruder (see above), you still need an Apple Developer account at $100/year and probably XCode to package it for upload "Application Loader", even if you can create the release files on another platform.
-
As for development, I have a Mac, and compilation and execution performance is several times faster with the Windows version in a VM on the Mac, than making native applications on the Mac. I don't know why, but Mac GUI components have been rewritten to not be slowed down by the 5K resolution, and maybe Lazarus and Forms don't yet take advantage of that.
I have "hackintosh" and on same hardware, mac compilation is faster than Windows. Problem is with LCL performance. Maybe too much repainting: https://bugs.freepascal.org/view.php?id=34829
-
As for development, I have a Mac, and compilation and execution performance is several times faster with the Windows version in a VM on the Mac, than making native applications on the Mac. I don't know why, but Mac GUI components have been rewritten to not be slowed down by the 5K resolution, and maybe Lazarus and Forms don't yet take advantage of that.
I have "hackintosh" and on same hardware, mac compilation is faster than Windows. Problem is with LCL performance. Maybe too much repainting: https://bugs.freepascal.org/view.php?id=34829
Do you have 4K/5K resolution, though? Apple have updated their OS at a low level to cope with the 7.1x higher pixel count compared to 1080p, and may take advantage of the GPU for GUI which Lazarus maybe doesn't? Anyway, this is a lot of theory from my side. I just noticed that it was slower in Mac OSX than in Windows in VM, and the VM is usually a lot slower.
-
....
As for costs, anything that needs XCode requires a yearly fee of $100 to Apple. You will likely also want to distribute over the App Store, ....
I am not sure thats actually the case. My application, tomboy-ng is pure Lazarus but I require XCode tools to build it. I do not pay Apple's $100 extortion, end users have to hold down a key when first starting the app, after that its OK. I do not distribute it via the App Store.
I appear to have a number of happy Mac users. Mainly I expect, ones who are, for what ever reason, forced to swap platforms regularly. One of the app's key features is its ability to sync its data between (cross) platforms.
Davo
-
....
As for costs, anything that needs XCode requires a yearly fee of $100 to Apple. You will likely also want to distribute over the App Store, ....
I am not sure thats actually the case. My application, tomboy-ng is pure Lazarus but I require XCode tools to build it. I do not pay Apple's $100 extortion, end users have to hold down a key when first starting the app, after that its OK. I do not distribute it via the App Store.
I appear to have a number of happy Mac users. Mainly I expect, ones who are, for what ever reason, forced to swap platforms regularly. One of the app's key features is its ability to sync its data between (cross) platforms.
Davo
It's the case since a few years ago. Without creating the files for signing your application (requiring a dev account), users who don't download the application from the App Store will all have to do the System Prefs maneuver.
-
[It's the case since a few years ago. Without creating the files for signing your application (requiring a dev account), users who don't download the application from the App Store will all have to do the System Prefs maneuver.
Which is for in-house development not really a problem. It is if you want to actually put it in the app-store. I have several applications running in a multi-user setting. You still need a developer license, though.
-
.....
It's the case since a few years ago. Without creating the files for signing your application (requiring a dev account), users who don't download the application from the App Store will all have to do the System Prefs maneuver.
Er, not sure what you mean. By "System Prefs" maneuver, do you mean the holding a key down while starting the app for the first time ? Or something more complicated ?
As I mentioned, my users are usually cross platform users, generally reasonably skilled and quite happy to fiddle a bit if necessary. I guess dedicated Mac users are probably less willing to step outside the Apple approved lifestyle. Windows users also have to go through a bit of a pantomime too, saying they are really sure they want to run an app by an unknown developer.
David
-
As for costs, anything that needs XCode requires a yearly fee of $100 to Apple.
No it does not. Xcode is free. Xcode commad line executables are also free. Download from the app store.
You only need to pay $US 99 to Apple if you want to sign and notarize your apps for distribution via the app store, or indeed if you wish to make installation of your apps more seamless than requiting the user to control-Click and choose to Open the app the first time. Your $99 also includes two Apple Technical Support Incidents.