WWDC gotchas for Xojo developers?

I have had an app I wrote in Xojo that has been able to do this for years now…

Drag-n-Drop controls, and the app generates a Swift App in about 5 seconds

The point with Swift UI is not about the drag and drop stuff (not new, predates Next, etc). What’s new (now on par with some other platforms) is the ease of use of the api, its declarative form, what is handles.…

[quote=439935:@Jürg Otter]According to this Article (in German):

App Notarization is now required
While one can do this manually with own CodeSigning Scripts or 3rd party tools… a decent IDE should have these features built-in.
So that’s going to be a “ToDo” for Xojo to make our lives easier.

zsh is the default Shell
Better check your Shell Scripts. Or make sure they are explicitly using the Shell you know is working with your commands.

And on the second Page of the Article (in German):
This is the beginning of the End of Objective-C
The new Combine Framework is only available for Swift. No more Objective-C support.

So in the mid/long term we probably want/need a way to use Declares working with Swift. Or the “Xojo Interops (to come)” work with Swift, too.
And (being pessimistic)… in the long term Xojo probably needs to add a new Build Target: “macOS (Swift)” to somewhen replace “macOS (Cocoa)”. So they better start preparing - who knows if that might be the case in 2-3 years. And I’m sure it’ll take quite some time to move the XojoFramework to Swift.[/quote]

That’s all really useful. Thanks, Jürg!

Will every app have to eb Notarized with no way to expect one from that?

I don’t have developer ID but as the Mac apps i write are for in-house use, notarization would really serve no real purpose… except maybe stopping from writing apps fro in-house use.

If getting a developer ID is and notarizing is or will be free, than it’s not an issue … If not then it could make writing in-house apps impractical for me…

  • karen

notarization will be a pain in the ass for large & small companies alike

[quote=439845:@Russ Lunn]hopefully im just being a pessimist…
I imagine IOS darkmode and iPadOS will push any xojo development for Windows, android and Web 2.0 even further into the future.[/quote]
Dark Mode for iOS 13 is actually fairly trivial for us to support.

Famous last words.

Bold statement Geoff.

We have already looked into this. We have looked at the APIs. We know what work we have already done. This is not a guess. We have done the analysis and it’s pretty simple relative to updating the framework and IDE for Dark Mode in MacOS Mojave.

Let’s not make a mountain out of a molehill.

Would be interested to know if anyone has iOS 13 beta and has maybe run the XDC app on it to test things out

Feedback assistant is a train wreck:

Thanks for chiming in, Geoff. Proper communication such as this helps to keep the guessing to a minimum and those mole hills stay small or get exterminated :D.

On the other hand, the proof is in the tasting of the pudding, so …

It already is. I’m not sure whether it’s automation or outsourcing, but I submitted the same exact notarization request for the same app with just a build number change. The first was refused while the second was approved.

I wonder how iPadOS factors into this

Right - thanks. I obviously was wrong with that BuildTarget “macOS (Swift)” part.
What I meant when I read that (some) newest frameworks are only available in Swift is: Should we/Xojo want to leverage these Frameworks, there will be Swift involved. Either that (part of) the XojoFramework needs to do that. Or that we developers might want a way to use “Swift Frameworks” in Xojo. Using Declares, Interops - whatever.
Or what @Dave S has mentioned.

Anyway - that part is currently the least impacting information from that Article mentioned (it might be a bigger one at some time in future).
The other pieces mentioned (Notarization required, zsh as default shell) will have an impact on many of us. And in my opinion Xojo should include some basic way of codesigning/notarization capabilities - it’s what one would expect from a development tool. And Xojo should already now check where their framework uses “Shell” internally - and if that’s working with zsh. And we developers need to have a closer look at our code where we’re using a Shell. And of course all the pre/postbuild scripts that might use Shell Scripts. Even if it’s as simple as to add a #!/bin/sh on the top to keep the current shell-behavior in the upcoming macOS, too.

[quote=439956:@Karen Atkocius]Will every app have to eb Notarized with no way to expect one from that?
I don’t have developer ID but as the Mac apps i write are for in-house use, notarization would really serve no real purpose… [/quote]
Most likely: Not required for “in house apps”, and not required for “to debug”.
But required as soon as you’re “distributing” it (via MAS it already is obviously, but now also if you’re providing your app as a download).

[quote=440017:@Jürg Otter]Right - thanks. I obviously was wrong with that BuildTarget “macOS (Swift)” part.
What I meant when I read that (some) newest frameworks are only available in Swift is: Should we/Xojo want to leverage these Frameworks, there will be Swift involved. Either that (part of) the XojoFramework needs to do that. Or that we developers might want a way to use “Swift Frameworks” in Xojo. Using Declares, Interops - whatever.
[/quote]
Yeah with the advent of Swift only frameworks I’m not sure whats going to happen since there are not header files etc to figure out declares into these things
They might be challenging

Hash bang has always been a good idea in a shell script

That said Xojo’s shell is a raw shell in many ways NOT a terminal session running sh, bash etc
Terminal runs a lot of startup stuff for you when you start it
Shell does not - and why you need to use full paths to many commands etc

This is just too awful (“allow Xojo access to the Documenta folder”:

Every application is supposed to use files. What are those dialogs supposed to help with?

wait for the details.
In the session it sounded reasonable.

e.g. you can write to document folder with our problems. You can read files you wrote.
Just you can’t read random files there.

This is not reasonable at all. What are random files??? I got a dozen of those dialog already. Apps are supposed to work with files.

I guess my app reading your documents and not only reading the documents my app creates.