Xojo is usually pretty tight-lipped about future releases with good reason. We, as users, usually hold them to features that they mention (even when they throw out the usual disclaimers about things might change) so it’s pretty unusual for them to offer any information on future releases. In the past month or so there has been information leaking out through the forum that says that Web 2.0 is in the later stages of development and they are pretty confident on the feature set.
We already know that Web 2.0 is using API 2.0. One thing we did not know until recently is that Web 2.0 is going to use the ill-fated new event names that so upset the community in the 2019 R2 release. We don’t know exactly what the events are going to be in Web 2.0 but we can safely assume the standard Open and Close events are now going to be Opening and Closing. I (naturally) have several thoughts about this.
First, I think the event name changes are needless. Opening is not more clear than Open. Closing is not more clear than Close. I think the new names are as meaningless as the originals. So I think using the new events names is a complete waste of time. Instead of the twenty plus years of institutional memory we all have with event names, not to mention documentation and example code we have to learn new event names.
It won’t matter for Web 2.0. Probably. I say probably because we don’t know for sure but the hint is that ALL of the Web 2.0 classes and controls will have new names and thus not affect the 3rd party market as much (although we can presume that anyone selling 3rd party controls for Xojo web has a big task in front of them updating them for Web 2.0). Does this class name change extend to WebApplication and WebSession too? Only time will tell.
Another reason why it might not matter is that subclassing controls in Xojo web apps was hard. Maybe non-existent? Regardless in our really big web projects we NEVER subclassed web controls.
If indeed every control in Web 2.0 is using a new name it eliminates much of the griping that we had with Xojo 2019 R2 because there is no existing market. It’s all new there are no naming conflicts.
Since events are added via dialog in the IDE most users will probably just roll with the changes. Since converting any Web project is a one-way process most users project won’t notice it. There’s still the possibility of Raising a non-existent event I suppose but I suspect that’s a more advanced feature many Xojo users don’t use and presumably the compiler will give a useful error message.
If the new event names are indeed the future it makes zero sense to have part of the product use Open and another part using Opening. So this means there are going to be new controls (presumably for desktop and mobile at some point) that have new unique names and therefore use the new event names. Again, same situation since if they have new control/class names there is no issue with conflicts. This is similar to moving from the old HTTPSocket to URLConnection with similar functionality but slightly different events.
This last point is the most important one. If Xojo hadn’t foisted the new events names in the old classes to begin with we wouldn’t be where we are at today. I still think the new event names offer zero clarity from the old names, but whatever. I’m just a user, don’t work for the company, and I’m not an MVP so my opinion doesn’t matter.
Okay, Xojo users. What are your thoughts on using the new event names in Web 2.0?
One last random thought: Because Web 2.0 sessions have been added at the Xojo Developer Conference (a.k.a. Xojo.Connect) I’m guessing that it will be released as a beta during the conference to attendees. I am not planning on attending so you’ll have to get your news elsewhere. This will be the first conference I’ve not attended since 2004 or so. Hope everyone has fun and gets a lot of useful information out of it.
Last week Xojo 2019 Release 3.1 hit the internet. This small bug fix release is a critical update and is recommended if you are using one of several areas. Let’s get into the details.
One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class. Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees. R3.1 fixes this issue and also a memory leak when using ODBC.
A couple of iOS bug were fixed in this release. R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular. iOSView headers no longer show the previous view during the PushTo animation. Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.
A number of API 2.0 bugs (besides the database bugs noted above were fixed):
TextArea.SelectionAlignment now accepts enum values.
String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
String.LastField now works
SerialConnection.Connect no longer raises an Error event. It now throws an exception as expected.
DateTime no longer reports a Nil TimeZone
In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.
In MacOS setting FolderItem.Visible no longer inverts the visibility.
The Plugin SDK now lets you access the new API 2.0 string extension methods.
The burning question that everyone wants to know: Do I think that Release 3.1 is safe to use? The answer is a definite maybe. Let me explain.
I’m still not sold on API 2.0 being completely stable. A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type. Both of these bugs are marked as fixed and ready for 2020 R1. Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.
If you’re using Classic API then I believe R3.1 is safe(ish). I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part. The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker. If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.
I have migrated a few projects to R3.1. A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade. R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.
So my advice is to test the heck out of your projects if you upgrade to R3.1. I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?
What is your experience with 2019 R3.1? Is it worthy? Are you holding back and, if so, why?
I’ve been a member of the Xojo community for nearly twenty years. In that time I’ve seen a lot of people join the community, become fantastic contributors, and then suddenly leave the community. There are a lot of reasons developers would leave the community but I thought I’d capture some of them.
Xojo scratches an itch and if the developer no longer has the need to scratch that itch they use a tool that scratches their next itch. Xojo is great for cross-platform applications but certainly less so if you need only a Mac or only a Windows application. Xojo’s strength is cross-platform which means compromises in abilities and controls so I can understand people wanting a pure Windows or MacOS application. Apple and Microsoft have large developer communities that are attractive.
The Rapid Release Program held much promise when it was introduced many years ago. Xojo went from two big monolithic releases a year to three, four or more releases per year. Sure, Xojo fixes a ton of stuff in each release but they also seem to break stuff in each release. I know we have a list of verboten releases for various platforms and it gives the impression of a perpetual beta status for Xojo. I have been a big fan of releases that are almost all bug fixes with no new features but those are pretty rare.
Xojo is a modern object oriented language and is quite powerful but it’s not a popular language. Many developers have never heard of Xojo. There is no standards committee that adds features to the language and the language itself is closed source. If there was a standards committee I suspect there would be some serious language additions done sooner rather than later. It certainly would have given much more forethought into API 2.0 and how it would affect the existing user base and the documentation done long before any coding started.
Xojo isn’t like any other development tool I’ve ever used. It’s great that it doesn’t allow a developer to make a stupid mistake when declaring a method. It forces you to use the Xojo IDE user interface to do everything from creating methods, declaring properties, constants, enums, etc. I’ve never used another developer tool that does this. Xojo pretty much forces you to use it the way they want you to rather than what most other languages do with a text editor. This makes it easier for beginners but if I’m being honest it’s a drag for someone like me that (usually) knows what they are doing. Forcing developers into the Xojo-way of doing things makes the IDE seem like a toy at times. It’s certainly slower.
Change does not happen quickly with Xojo. It has a small development staff and I’m always amazed at how much they get done. But it means that it can take an incredibly long time for things to change and become stable. The transition to 64-bit was a huge multi-year project. iOS was a huge multi-year project. Web 2.0 and Android have become huge multi-year projects (with still no idea on when we’ll see them). The new targets might be good eventually but history shows it will take a few releases before they’re really stable. Meanwhile older targets seem to get significantly less attention.
Xojo isn’t really a business development tool. When I say business I mean databases and reports because that’s practically every application we’ve done for the past twenty years. Doing database development in Xojo is NOT Rapid Application Development (RAD) because you have to deal with everything database related yourself and the IDE and compiler give you zero help. Reports are simplistic and aren’t exceptionally powerful and there’s no way for an end user to create or edit reports. There’s a reason why BKeeney Software has its own database Object Relation Model (ORM) classes and reporting tools and classes because we have to use them in nearly every project we do for clients.
In addition to all that it’s really missing some things that business users need. The TextArea control has pitiful RTF support, there is no built-in calendar, date, or time controls. The built-in grid (Listbox) is more powerful than many people give it credit for but cannot hold native controls and can be very slow with large data sets. There is no PDF read or write support either. There are 3rd party options for all of these things but something lightweight would go a long way to supporting new business users.
These are a few of my thoughts. What am I missing about developers that leave Xojo? And is there a way to stop them from moving away from Xojo? What are they doing to?
Xojo announced today the creation of the Most Valuable Professionals (MVPs) advisory board. More information here: https://www.xojo.com/mvp/
Having ‘known’ these five Xojo developers for many years (mostly online and a few in person) I think they are an excellent group to advise Xojo. Most of these developers have many years of Xojo experience ranging from being 3rd party control and library developers to consultants to commercial application developers.
It makes me happy that every single one of the developers on the Advisory Board is what I would call part of the ‘professional’ developers of Xojo. It is surprising, however, that there are no ‘citizen’ developers on the board. So I call this a mixed signal to who Xojo is trying to appeal to (obviously it’s everybody but I think you get my point).
The Association of REALbasic Professionals (ARBP) tried to do this ten years ago with no success. The groups mission was to help inform Xojo (then Real Software) on what the professionals wanted out of the tool. If I recall correctly the only thing that was ever implemented out of our top 5 list was reporting. Grids, PDF support, and more basic controls never materialized. Sadly, we all still want those options.
It’s not being said but I believe the MVPs Advisory Board is a direct response to the virulently negative (and vocal) reaction by some Xojo developers had with the rollout of API 2.0. I am one of those developers and it is no big surprise that I was not invited to be on this board and, if I’m being honest, I’m not sure I would have accepted anyway.
We don’t know how the advisory board works, or even if it will significantly change how Xojo approaches future changes. Even if they do have significant input I’m not sure we’d know unless Xojo specifically tells us.
Good luck to this group and Xojo: There are some relationships to mend.
Now that API 2.0 is more or less been through two releases (2019 R2.1 and 2019 R3) many Xojo developers are starting to poke around with API 2.0 in their database applications. There are many things to like about the changes to the database classes and our own ActiveRecord class does many of these things. Things like throwing exceptions when there are errors definitely get your attention whereas in API 1.0 unless you check for the error you may not know anything bad happened. The built-in Prepared Statements are a super nice change too.
Despite all the good things with the db classes in API 2.0 I recommend holding off until one, very important bug, is fixed. Feedback case 58739 is such a huge risk that you simply cannot use the new API 2.0 classes in your Xojo projects yet.
The essential detail of that case is that Xojo is not releasing objects as it should. Norman did a test case and showed that when using API 1.0 his test project had 24 objects at the end of the test run. Doing the same thing in API 2.0 had over 43 million still unreleased objects! This means there is a huge use of memory in the application and in 32-bit applications it will simply crash once it consumes 4 GB of RAM. 64-bit applications will last longer but still bring your computer to its proverbial knees.
The Feedback case talks about SQLite and in-memory databases but other reports are that it’s in other databases as well including ODBC and MS SQL Server (case 57978). The good news is that 58739 is marked as fixed as of January 7th, 2020 (57978 has not been updated). But unless Xojo issues a point release to 2019 R3 we won’t see this fix until 2020 R1 is released and there is zero evidence of that happening any time soon.
Several people have contacted us about an updated ARGen that generates API 2.0 code. We are holding off until we feel API 2.0 is rock solid. So until this is fixed we are not using or advocating for API 2.0.
Have you found anything else in API 2.0 that should discourage Xojo developers from using it?
Last week we asked the question “How Did You Find Xojo?” A vast majority (60%) of the responses said web search of some kind was how they found out about Xojo (or REALbasic or Real Studio). Some found Xojo via software discovery CD’s that were bundled with Mac specific magazines over a decade ago (that seems wrong to write it like that).
More than a few users had comments that they had been using Visual Basic (VB) and wanted something like it for the Mac. Some even said that they searched for “VB for the Mac” and Xojo was one of the results.
I get it. I spent quite a few years working on a big accounting application written in VB6. It was big enough where we had to refactor the project because we couldn’t add any more modules or class objects to it. It used many third party controls that helped in development (think text field formatting, fancy grids that could hold any other control, and multiple reporting tools).
The project was only ever going to be on Windows so there was zero thought about a Mac version. But that didn’t stop me from thinking about it. Every now and then I’d try to do something in Xojo to prove that I could do it. With the exception of the fancy grid there were few things I couldn’t get working in Xojo.
Even though VB6 and Xojo are BASIC languages there isn’t much similarity between them. VB6 compiled applications that required the VB6 runtime while Xojo applications are compiled into self-contained packages. On the Mac everything required by the application is in the bundle whereas on Windows and Linux libraries needed by the app are put into a folder right next to the executable. Xojo Windows apps don’t need to use an installer but since Windows users expect an installer it’s easy enough to use.
VB6 is over fifteen years old. It didn’t have much in the way of modern language features such as object inheritance. You spent a lot of time and effort manipulating controls to do what we’d consider ‘normal’ things (I seem to remember ListBoxes being this way). In Xojo you can extend and subclass practically everything. Is Xojo a perfect language? Oh heck no, but it’s light years ahead of the fifteen year old VB6 and it’s still evolving and improving.
Xojo doesn’t make perfect Windows, Mac, or Linux applications. It’s often a compromise for something that works ‘well enough’ on Mac, Windows, and Linux applications. So the fancy grid’s that you could purchase for VB6 don’t really exist for Mac and Linux and Xojo reflects that. But you can certainly design a really good application that doesn’t need the fancy grids. MacOS users tend to like ‘elegant’ solutions and, to be honest, the fancy grids aren’t an elegant solution but they certainly work (especially for accounting applications).
The third party community for Xojo isn’t nearly as big as the VB6 world. Generally there are fewer options but the options are considerably less expensive. We’d spend a couple of grand each year per developer on licensing for third party tools. As a Xojo consultant we spend about that much for the entire staff each year.
We don’t get many requests for VB6 to Xojo conversions any more. We used to get ten to twelve a year but it has definitely slowed down the past couple of years. I suspect that any remaining VB6 applications are in maintenance mode and their owners don’t want to invest in a rewrite. If they did, they would have already moved to a new development environment.
VB6 applications still work in Windows 10 and if memory serves Microsoft has said they’ll support the VB6 runtime for another ten years. This means that there must be a LOT of VB6 applications still around. Support for the VB6 IDE has disappeared and the last time I tried I couldn’t get it to install properly in Windows 10 so I just went back to my Windows 7 VM. But now that Windows 7 support has expired it seems that those old VB6 applications might be on life support.
Many of us came in to the community looking for VB for the Mac. We’ve been using it for nearly 20 years and have a stable of clients that are happy with a single code base for their commercial Mac and Windows (and occasionally Linux) applications. I’d say Xojo has been more than good enough.
I’ve been on the search, recently, for alternatives to Xojo. I’ve done some basic research into Lazarus and RAD Studio and both came up short in a variety of ways that you can read about in past posts. So what am I looking for in cross-platform development tool? I’ll spend the rest of this post talking about some of my requirements.
Most of our consulting work is macOS and Windows with the occasional Linux or Raspberry Pi project thrown in for good measure. Whatever development tool I choose it needs to be able to build for Mac and Windows at a minimum and anything it can do with Linux is an added bonus. Rarely do we get a project that is just Windows or just MacOS. Being able to desktop and consoles apps is a must on each target platforms.
Maybe it’s my Mac background but I’d like my controls to be as native as possible. This means that when Apple, Microsoft, or Linux distribution changes their UI (again) the application will just work without requiring an update from the vendor. I’ll be honest that this is a want-to-have option as even Xojo isn’t completely 100% native (Listbox I’m looking at you). Accessibility is a big concern for some clients so I’m willing to forego native if it’s ‘close enough’ and works.
I’m a Mac user so I’d like to stick to my platform of choice if I can. This means that the IDE must have the features that I come to expect on the Mac (keyboard shortcuts, standard Mac text editor features, Finder integration, and so on). Can I live with working in Windows? Sure, but remember I’m searching for unicorns so it’s not my first choice. Plus, having a Mac IDE is a good indication how good of a cross-platform development tool it is. I find it laughable, really, that some companies create cross-platform applications but yet don’t have a Mac IDE. Um…so do you *really* do Mac applications or is this a marketing checkbox?
I’ve been doing Rapid Application Development using Xojo for nearly 20 years and while you could argue that parts of Xojo are not very RAD (database development I’m looking at you) it is very easy and simple to get simple applications developed in practically no time. Just last week I was able to get a simple Mac/Win desktop application developed for a client in four hours and that included preferences, full menubar, a simple text editor, talking to a web API, all with code signing, notarization, and installers. Some of that is experience and the kit that I’ve developed over twenty years but some of that is simply Xojo. Xojo makes it easy to create a MenuBar and quickly create menu handlers at either the application or window level. The integrated Layout Editor makes it easy to add events for the window and controls and automatically drops into the integrated Code Editor. I really want the next development tool I choose to be as easy to use as Xojo so I can get work done quickly and efficiently.
As a bonus I’d like my IDE to have integrated git and/or subversion integration. I’d also like built-in code signing and notarization if possible too. I realize this last part might require some remote magic since only a Mac can code sign and notarize Mac applications. Neither of these options are available in Xojo at this point and require command like voodoo or a third party utility.
Double-Clickable, Compiled Executables
I really need my apps to be double-clickable in the Finder and Windows Explorer and just run. I should never have to start up an application with the command line nor should I have to have a runtime installed to run the application. Xojo applications are packaged to run independently and on the Mac they are in a bundle and even in Windows and Linux they are self-contained builds not requiring anything special from the operating system (as in no runtime necessary).
Community Size and Friendliness
I’d like my new development community to large and friendly. When I have those inevitable questions regarding my new language and IDE I want a lot of options and where the community isn’t full of jerks. For all of its issues this is where Xojo really shines because it’s one of the most helpful and friendliest communities I’ve ever been part of. I’ve seen the vitriol spewed in other communities when newbies ask a question that should probably be obvious. Hey, mistakes happen, and what’s obvious to one person may not be obvious to another.
I’ve spent the last two decades as a consultant so why would I stop now? Whatever community I go to I’d like there to be a decent consulting community where an up and coming developer could make a name for themselves. I have no problem becoming ‘certified’ (whatever that means) to get listed and to get prospective clients.
Large 3rd Party Ecosystem
One complaint I’ve had about Xojo over the years is the lack of 3rd party options for controls and libraries. If you want reporting options, a better grid, PDF creation and viewing, database ORM options, and a whole host of other controls and libraries your options are extremely limited. My new development tool should have a vibrant 3rd party community so I don’t have to reinvent the wheel in many projects. I’m okay paying money for a quality controls and libraries but what I really want are options because each one is different.
Good Documentation and Examples
This seems pretty self explanatory. The documentation should be sufficient to learn the language. In an ideal world it would be fully fleshed out so you can get a feel for the gotchas. As far as examples go they should just work without having to futz around fixing stuff.
It can do web apps.
It can do iOS and Android mobile apps (with some of the same caveats above).
The company/community behind it has a roadmap and what they want the language and IDE to be in the long run.
A standards organization behind the language.
A large enough company behind it, or a large enough community, to ensure future new features and timely bug fixes.
The things that I’m NOT concerned (much) about
Pricing – if it works then the price is (almost) irrelevant.
Licensing – if the language, IDE, and controls and libraries let me create commercial applications then I don’t care if it’s an MIT, GPL, LGPL, or Commercial license.
So that’s my unicorn list. If Xojo is not going to be my long-term development tool these are the things I’m looking for. Is this an impossible list? I don’t think so but as someone coming FROM Xojo these are the things I’m looking for. I you have some suggestions, I’d like to hear them and please let me know what the tool does NOT have from my list above. I know it’s highly subjective but I think it’s important to acknowledge the limitations of the language and tool you work with every day. Like Xojo, no development tool is perfect.
Xojo 2019 Release 3 hit the internet today. It’s only been three weeks since R2 was released and while this release has a number of bug fixes that are important this release is mostly about iOS.
R3 introduces a new ColorGroup class that will eventually come to all targets but for now it’s only available for iOS. The ColorGroup has its own editor and allows the developer to set or choose colors they want to use. You can choose Single, Dual, or Named colors. I’m not entirely sure the point of the Single color, but Dual allows you to change a single color based on Light or Dark mode, and then there is the Named option.
I feel that the Named option is the more valuable of the settings as it allows you to select what type of ‘color’ you’re using and allow to use, or modify the default colors in Light or Dark Mode. For example, if I simply wanted to use the default colors of an iOSLabel I can select the ColorGroup from a new popup in the Inspector. The control then will automatically use the Label color. But if I want to override the defaults I can do so here for both Light and Dark modes.
This has the promise to help Xojo developers that are supporting Light and Dark Modes in their applications. Since it’s currently for iOS only and I’m not actively working on an iOS project I can’t speak to its effectiveness and usefulness in coding. I feel that the ColorGroup editor was slow to respond to color picker changes. If you have some firsthand knowledge of the ColorGroup in action please leave a comment below.
The iOSTextArea control has a new Border Style and Border Color properties that allow you to create rectangle and rounded borders. SF Symbols can be retrieved by the iOS framework using the iOSImage.SystemImage shared method. The iOSRectangle now supports Blur effects.
After iOS there are number of new additions and changes that are part of the API 2.0 work. If you are interested please read the release notes. I am not actively using API 2.0 in any projects so these changes don’t mean anything to me yet.
Some Windows bug fixes: The Draw Caution/Note/Stop icons are updated to the newer look for Windows Vista and later. The app now terminates when the system sends a shutdown message (like when an installer is trying to update the app). The GroupBox no longer draws funny when the caption font size is different than the default.
Some Linux bug fixes: Changing the Label Text Color no longer leaks memory. Clipping the listbox graphics in the CelLTextPaint or CellBackgroundPaint now works as expected.
With iOS Dark Mode out of the way, hopefully this means that 2020 R1 will have the long awaited Web 2.0. My gut feeling is that Web 2.0 won’t be released until Xojo.Connect at the end of March and even then it might be only in beta form. Web 2.0 is a complete rewrite from the ground up that’s been underway for a while. Maybe I’m wrong but experience says they’ll want something big and flashy to show off. Of course I also expect more from Android but I still expect that to be in alpha and nowhere near ready for release.
R3 is mainly an iOS release for Dark Mode and some changes for API 2.0 and then mostly bug fixes. As always, before using you should read the release notes and then thoroughly test your application before issuing any releases.
In my quest to find a Xojo alternative I came across RAD Studio https://www.embarcadero.com/products/rad-studio that is owned by Embarcadero. RAD Studio can work with C++ or Delphi (object Pascal) and build for Windows 32 and 64-bit, MacOS 32 and 64-bit, Linux, Android, and iOS depending up on the license. They also have a Community Edition that can build for Windows, macOS, Android, and iOS but is free until company revenue reaches $5,000 or you get to 5 developers.
The RAD Studio IDE is Windows only even though it will allow live debugging into the other target environments. For my testing I was running the IDE using Parallels 15 in Coherence Mode running Windows 10 64-bit. The VM resides on an external SSD via Thunderbolt 2. I found the environment to be responsive despite being in the VM environment.
During installation it asks if you want C++ or Delphi for MacOS, Windows 32 bit Windows 64 bit, Linux, Android and iOS. I selected Win32 and MacOS. It took a good 15 minutes to install. You definitely need a large VM to do this. I ran out of space on my VM and had to start over again after clearing up some space.
To start testing, I created a New Multi-Device application. Doing a Hello World was simple enough. Double click on the on the label in the Palette, or drag and drop onto the form. Scroll down in the Object Inspector and change the Text property to “Hello World”.
At this point I’m ready to rock and hoping for the best. Pressing the Run button runs the app and voila a Windows app with a window saying “Hello World” pops up. Passes the first easy test. But what about getting the Mac version going?
To set up for the Mac (or iOS, Android, Linux or even another Windows computer) you’ll have to install the Platform Assistant Server (paserver for short). Paserver is a command-line application that you install on Windows, macOS, and Linux so that RAD Studio can connect and do its thing.
I had to read through the help file to figure out how to do this. PAServer20.0.pkg is located in C:\Program Files (x86)\Embarcadero\Studio\20.0\PAServer and you copy it to the Mac side to install it. The PAServer installer is using a code signing certificate that’s expired but it’s easy enough to work around. The installer puts two applications in your Applications folder: PAServer-20.0 and PAServerManager. But for now we’re only concerned with the PAServer-20.0 application. Go ahead and double-click to start it.
This opens the Terminal and the first thing it asks you for is a Connection Profile password. I set it to blank for ease of setup. It automatically opens port 64211 and a Mac security prompt immediately pops up asking if I want to allow incoming connections.
Going back into RAD Studio if I go to the project listing that shows my targets and I select Properties from macOS 64-bit I can setup my paserver now. Select which SDK to use (Mac 64-bit), then input the TCP address of the Mac. Test the connection and then select OK. A bunch of files get copied over to the Mac side.
Trying to debug run the application on the Mac side generates an error. Module not found: dccosx64260.dll After contacting the sales rep for help it appears that I had version 10.3 Update 2 and the fix for this problem was in Update 3. Maybe I just missed something in the myriad of menu’s but I never did find an “Update” in the application. I had to go to their website and search for updates and download an updater. The updater then proceeded to uninstall the previous version and then proceeded to give me the default settings (not what I’m looking for). It seems that the installer is pretty stupid. But it installs.
This is really where my review should end. After spending a number of hours trying to get this working I was unable to actually see a Mac app running. Despite updating the entire RAD Studio (twice) and update paserver I could never get any of the demo apps to run on the Mac. I know this works since I saw an Embarcardaro engineer do it. I’m sure it’s something I’ve done wrong but I figure if I can’t figure it out in a couple of days of messing with it then it’s not a trivial issue. It was very frustrating.
Initial thoughts on the IDE: This is a very typical 90’s looking MDI Windows application with one big overall window with various smaller windows inside of it. I find it to be very busy but not awful. I can live with it. I have to remind myself that I’m a spoiled Mac user and I expect ‘pretty’ and functional UI from every application.
The Projects list shows all of the available targets and seems pretty straightforward. This window disappeared on me once and the only way I found to get back to it once reopen the project. I’m sure there’s some menu command to get it back – I just couldn’t find it.
The Object Inspector is listed alphabetically and not grouped into functional groups. It has two tabs, Properties that shows the properties and Events which shows the available events. Double clicking on a control, like a Button, automatically drops you into the Code Editor and into the Action event. All code for a form or library is available as a complete text file rather than the way Xojo presents it to the user in a singular fashion (i.e. you get to see one method, property, or event at a time regardless of your coding skill level.
Here’s where things got really confusing for me. A multi-device project has one library (FMX) whereas a Windows-only project could use that one or one called VCL. Then there’s the choice of what language to use C++ versus Delphi. I was really confused on how to even figure out how to do a simple message box on the click event. I don’t see this as a huge problem as it’s common with learning any new framework so it’s just a matter of finding the right documentation and doing some reading. But it is a little concerning that I wasn’t able to find this readily. It was frustrating.
Code signing is built-in for all target types. For Mac deployment (assuming you can get it working) has built-in Notarization but it should be noted that you have to have a Mac and use paserver application to do code signing and notarization.
Another interesting thing is that you can have Windows, Mac, Linux targets all in one project file. That’s not too much different than Xojo but what’s also interesting is that you can have Android and iOS targets as well. The form editor gives you a simulation of what the UI looks like native to that platform. I’ll be honest, it’s not a great simulation but it’s enough for you to get the gist of how it will look. Of course, it’s convenient that you can reuse code amongst all of the targets in the same project.
During a demo with a sales rep and engineer I asked if the Mac controls were native. They said they were but I can say with 100% certainty that the standard tab control in RAD Studio is not using the standard Mac tab control (that looks like segmented buttons centered on the page). So I wonder about the veracity of this claim. I could never verify this as i was unable to get a Mac app running on my machine.
RAD Studio has considerably more built-in controls than Xojo. It really puts Xojo’s control library to shame. It has everything to get going without having to jump to the 3rd party market. However, when you do need something not provided (or that needs more features) there is a window to find them. Simply go to the Tools->GetIt Package Manager menu option and use the search field to find what you need. Additional filters allow you to see all, free, already purchased items and so on. Need a PDF viewer, reporting tool, or advanced grid? It’s in the list along with details about it and it has a convenient Install button right there.
RAD Studio is more expensive than Xojo but it does things that Xojo cannot currently do (Android for example). To create macOS, Windows, Android, and iOS applications it costs $2540 for the first year and that includes all major updates, hot fixes and ongoing maintenance of previous releases, and 3 developer support incidents. The Enterprise license allows you to do client/server databases, build for Linux, and build REST API applications for $4217.
In many ways, RAD Studio is what I wish Xojo was striving for. It has a definite “we’re serious” feel to it. The 3rd party integration is really nice. The documentation is very expansive and relatively easy to find things although as I noted above I had issues figuring out how to do a simple message box. It is nice to see that they have hot fixes available rather than having to wait for a major update.
For a company that touts its cross-platform development capabilities I find it kind of funny that they don’t have a Linux or Mac version of their IDE. If they did I think they’d learn a few things about making Mac applications in making their IDE truly cross-platform.
The fact that I’ve struggled to find answers to installation issues says that it’s not an easy language and IDE to learn. I suspect that having dual languages (C++ and Delphi) along with multiple UI libraries makes getting started much tougher than it needs to be. Getting the cross-platform applications working seems to be finicky and while I’m sure it works I threw my hands up in frustration.
Yes, I’m spoiled because the Xojo IDE (mostly) works the same on Mac, Windows, and Linux and compiles for the other platforms without needing to run a special app on the target platform (iOS requires a Mac but that’s an Apple restriction). While it’s true that there have been hiccups with API 2.0 the language is still undeniably Xojo and the Language Reference is decent with working code examples. Where Xojo is deficient is in default controls (like Date, Time, Calendar) and there is zero 3rd party controls/libraries discoverability in the Xojo IDE.
If you have a different experience with RAD Studio I’d love to hear from you. Are you doing macOS and iOS development with it? Did I do a fair review (keep in mind I’m coming from a Xojo)?