WWDC gotchas for Xojo developers?

  1. ‹ Older
  2. 10 months ago

    Norman P

    4 Jun 2019 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    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

    4 Jun 2019 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

    4 Jun 2019 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

    4 Jun 2019 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

    4 Jun 2019 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro outside avoiding snowflake

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

  8. Geoff P

    4 Jun 2019 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro Kansas City

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

    Famous last words.

  10. Joost R

    4 Jun 2019 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

    4 Jun 2019 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    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

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

    Feedback assistant is a train wreck:

    -image-

  14. Tim J

    4 Jun 2019 Pre-Release Testers, Xojo Pro N. Phoenix, AZ
    Edited 10 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro N. Phoenix, 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    I wonder how iPadOS factors into this

  17. Jürg O

    4 Jun 2019 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

    4 Jun 2019 Pre-Release Testers, Xojo Pro outside avoiding snowflake
    Edited 10 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

    4 Jun 2019 Pre-Release Testers, Third Party Store Europe (Germany)
    Edited 10 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

    4 Jun 2019 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

    4 Jun 2019 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!