WWDC gotchas for Xojo developers?

  1. ‹ Older
  2. 5 months ago

    Norman P

    Jun 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    Cocoa is the UI kit / framework which is unrelated to the language it was built with
    Swift is still "cocoa" just done in Swift

  3. Dave S

    Jun 4 San Diego, California USA

    @Michael D One big "innovation" of SwiftUI is that you can drag a control onto a window, and the code to generate it is magically created, and you can double-click the control to see the code.

    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

  4. Philippe S

    Jun 4 Pre-Release Testers, Xojo Pro

    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.…

  5. Tom C

    Jun 4 Pre-Release Testers, Xojo Pro Europe (London, England)

    @Jürg O 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.

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

  6. Karen A

    Jun 4 Pre-Release Testers

    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

  7. Norman P

    Jun 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    notarization will be a pain in the !@#$% for large & small companies alike

  8. Geoff P

    Jun 4 Xojo Inc Austin, Texas

    @Russ L 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.

    Dark Mode for iOS 13 is actually fairly trivial for us to support.

  9. Bob K

    Jun 4 Pre-Release Testers, Xojo Pro, Third Party Store Kansas City

    @Geoff P Dark Mode for iOS 13 is actually fairly trivial for us to support.

    Famous last words.

  10. Joost R

    Jun 4 Pre-Release Testers, Xojo Pro The Netherlands

    @Geoff P Dark Mode for iOS 13 is actually fairly trivial for us to support.

    Bold statement Geoff.

  11. Geoff P

    Jun 4 Xojo Inc Austin, Texas

    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.

  12. Norman P

    Jun 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

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

  13. Beatrix W

    Jun 4 Pre-Release Testers, Third Party Store Europe (Germany)

    Feedback assistant is a train wreck:

    -image-

  14. Tim J

    Jun 4 Pre-Release Testers, Xojo Pro Dehydrating in AZ
    Edited 5 months ago

    @Geoff P Let's not make a mountain out of a molehill.

    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 ...

  15. Tim J

    Jun 4 Pre-Release Testers, Xojo Pro Dehydrating in AZ

    @Norman P notarization will be a pain in the !@#$% for large & small companies alike

    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.

  16. Norman P

    Jun 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    I wonder how iPadOS factors into this

  17. Jürg O

    Jun 4 Pre-Release Testers, Xojo Pro

    @Dave S Um.... not sure that makes any sense. SWIFT is a language, as is Xojo.... where as Cocoa is the underlying iOS framework that both "languages" use...

    @Norman P Cocoa is the UI kit / framework which is unrelated to the language it was built with Swift is still "cocoa" just done in Swift

    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.

    @Dave S Now it would be cool if it were possible to write plug-ins or custom controls/methods in Swift and link them into Xojo

    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.

    @Karen A 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...

    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).

  18. Norman P

    Jun 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog
    Edited 5 months ago

    @Jürg O 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.

    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

    @Jürg O 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.

    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

  19. Beatrix W

    Jun 4 Pre-Release Testers, Third Party Store Europe (Germany)
    Edited 5 months ago

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

    -image-

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

  20. Christian S

    Jun 4 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

    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.

  21. Beatrix W

    Jun 4 Pre-Release Testers, Third Party Store Europe (Germany)

    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.

  22. Newer ›

or Sign Up to reply!