I agree 100% with #1 and #2 both.
I’m playing with a project right now that while using Standard Swift (not SwiftUI) is designed to be compiled for macOS, iOS and tvOS (that last one being the biggest challenge). macOS uses AppKit/Cocoa while iOS and tvOS use UIKit. So to lessen the amount of code fenced by compiler directives I have created a series of typealias definitions similar to this
#if !os(macOS)
import UIKit
public typealias aliasFONT = UIFont
public typealias aliasVIEW = UIView
public typealias aliasCOLOR = UIColor
#else
import Cocoa
public typealias aliasFONT = NSFont
public typealias aliasVIEW = NSView
public typealias aliasCOLOR = NSColor
#endif
there is still of course platform specific code, but considerable less, and mostly in the syntax surrounding things like touch vs mouse events
That’s similar to some of the concepts behind Catalyst — using two sets of classes (one for AppKit, the other for UIKit) linked by either conditionally-compiled typealiases like you’ve done or small classes that will call either UiKit directly if running on iOS or bridge code fro handle different methods or arguments on AppKit…
My gut feeling is that Apple will continue to try to abstract away the platform as much as possible so we don’t have to write much device-specific code, if any at all, in the future. At least we will not need a deep understanding of both iOS and Cocoa.
Both SwiftUi and Catalyst are in their infancy. If you use Twitter, follow https://twitter.com/steipete?s=09 as he’s done a lot of work with both these technologies in attempts to make really Mac like Apps (and yet still work on iOS and iPadOS).
I realize that. It’s all still limited to Apple platforms. But it’s still cross-device — nearly identical code for macOS, iOS, iPadOS, watchOS and tvOS. That makes it extremely useful for Apple developers.
I could concentrate on the desktop, but the approach would be much different depending upon whether I use SwiftUI vs. Catalyst. For macOS apps using SwiftUI, any need to add platform-specific code beyond SwiftUI would require AppCode calls. For Catalyst, most of the calls outside of SwiftUI are via Catalyst, which is more iOS-like.
Before I start, I need to know which approach readers would be more interested in: (1) directly working on macOS only (outside of SwiftUI) with AppKit, or (2’ writing all of their apps for both the iPad and Mac with more iOS-like code, which reduces the learning curve a bit but prevents is limited to those two types of devices only.
The advantages and disadvantages of approach 1:
Only AppKit must be covered, but the reader learns more about macOS-specific coding, which is covered less than UIKit in most tutorials.
The reader must figure out how to add mobile coding with UIKit later and add it with platform-specific code.
The only shared code for all platforms is for the GUI (although it may still require device-specific tweaks).
The advantages and disadvantages of approach 2
Code can target both mobile and desktop systems at the same time mostly using one framework.
This might reduce the learning curve for both types of devices, but it is limited to those two types of devices only.
More code is shared between devices.
When we must drop into platform-specific code, even though it’s rare, we still need to know both AppKit and UIKit.
Your Approach 2 was my Approach to use Java with GluonMobile. The code can be shared directly between Desktop and Mobile (IOS and Android) and Desktop is covering all operating Systems. The price I have to pay is: no native GUI in Desktop use. For Android and IOS there is the use of native GUI. One Code for all platforms and one GUI for all platforms is in that way possible.
and don’t forget the most maligned of Apple Platforms… tvOS
its logic is 100% iOS type code… but the User Interface is TOTALLY different, and depends on the app as to what methods you employ. I have one app I wrote where the user interaction is handled differently on each view… partially because I was learning as I went, but also because in some cases each method lent it self better to the requirement
After months of coding (mostly in my spare time), two weeks ago I released my first web application written in Java (using the Apache Wicket framework). It runs on an Apache-Tomcat server using a PostgreSQL-database with connection pooling, so it can handle many parallel connection. It is an in-house application which was originally written with X…o Web.
Question: How long did it take to write the application compared to X…o?
Development time was significantly longer (probably three times the time) than with X…o, but of course this was my first Java web application and I had to learn new stuff all the time.
Question: Does the new application leak memory when running for a long time?
Answer: No.
Question: Are the pages loading slowly or is there a slowdown when the application runs for a longer time?
Answer: No, the pages load fast as lightning.
Question: How many bugs (Java or Wicket) did I encounter during the past 8 months while developing the application?
Answer: Zero.
You’re welcome in the Java Edge. Wicket is a rock solid bullet proof framework. Your next app will need the time you would need with xojo or even less. Good decision.
I’ve been following most of the threads on this forum for quite a while now and I can only but agree with a lot of the criticism regarding the running of Xojo as a company rather than the functionality of the product.
I dropped Xojo as a product over 18 months ago and didn’t renew my license nor did I renew any of my third party product licenses except for the Chilkat plugins I was using (this was because I used them in the language I switched to). I was blown away by the lack of functionality in the released version of Web 2 and the amount of bugs that were consistantly not getting fixed release after release.
I found the feedback system as about much use as a chocolate teapot with the majority of problems either being marked as unreproducible or that were just being plainly ignored altogether.
Out of the 14 products / tools I had written over the last 8 years for a couple of my customers I have rewritten 8 of them in Purebasic. Purebasic is cross platform and currently produces ASM output which is then compiled using fasm. For cross platform you do need to run the IDE and compile on each individual platform but for me that is not a problem as all my customers are on Windows. The next version of Purebasic will actually output straight C code and enable inline C, it will still need the IDE to be run on the required platform but will open up almost every possible architecture bringing the mobile platforms into play as well.
Since moving over to Purebasic I have had very few problems porting my software and the speed improvements in some cases have been amazing.
There is a very active and friendly forum with people always willing to help (very much like here).
By continuing to use the Chilkat plugins (modules) which are useable in so many languages, I have so far not come up against any show stoppers. I can safely say I’m in a much happier place now than I was when I was struggling with some of the errors I was encountering in Xojo.
Luckily I only have one legacy Xojo web 1 app that is still in use by one of my customers but it only has a limited lifespan now of a couple more years so the 2015 version of Xojo that I used to write it is ample to maintain it and make any changes required in the short term.
I don’t regret moving away from Xojo in the least, I have a business to run and making money for both myself and my family is priority No. 1. I am on the other hand sad that Xojo has gone in the direction it has, and to be honest I think the departure of Norman was probably the nail in the coffin for both Xojo and its reputation. They have an owner that just does not listen to his customers and forces his staff to defend his dicisions which isn’t helping them or their own reputations, add in the pot new MVPs and the forum has become a dictatorship where no one can have an opposing opinion or a constructive conversation without be locked out and banned for life time.
It is a sad state of affairs and I can personally only see free software or cheaper alternatives forcing Xojo out of business eventually and at the same time bringing down the likes of Christian (MBS), Einhugur and the other third party plugin suppliers with it.
I also have a Purebasic license. I find the syntax to be kinda weird and I don’t like how the database access is handled. Unless I am mistaken, its really hard to have multiple connections to the same database (i.e. Postgres).
Just my opinion… it is extremely fast and produces really small executables.
Most of the users here and many others that have left Xojo feel this way. It is a shame that all that the blind owner can see is “atacks”.
Sad but true
Can you share a little more details about the bumps, and if it is posible, some screens comparing the Xojo Vs the Pure basic versions of one of your products?
@dickey, I also have a SpiderBasic license and was thinking of porting my web 1 app. As SpiderBasic produces JavaScript which obviously runs client side I started to write the server side as a Fast CGI in PureBasic, but time constraints and the life expectancy of the app I’d written for the customer didn’t really make it viable for me.
I also started to write a small server in PureBasic that would serve the SpiderBasic JavaScript making a more standalone application like a Xojo web app. Again customer work and family commitments never really leave a lot of time for experimentation.
@pjsmith67, The syntax can seem a bit weird coming from other languages but like anything else once you’ve grasped it it’s really quick and easy to produce great compact code.
I’ve only used ODBC for the database side of things and only in connecting to SQL Server. I just use a single connection for my query’s, a connection for any updates and another for any inserts. This is only required though if you are doing updates or inserts from within a query loop.
