As a “citizen developer” I’ve written about 8 iOS apps but my needs are simple and I don’t need declares. That’s where Xojo is fine for iOS.
I believe he meant making your own app, not just following an online course with step by step instructions.
Such good feedback - thanks!
I think for this next app I’ll be using Xcode but I don’t think we should rule Xojo out of the running for iOS development altogether. The Xojo IDE is far easier to navigate than Xcode and the ability to (potentially) share code between Windows desktop and iOS is enticing.
I think Xojo needs to make a concerted effort to double down on iOS rather than add Android as yet another platform. I don’t want them to leave it half-baked. Perhaps I’m being unreasonable but 3 years after launch seems a sufficient amount of time to wait for the core functionality of the language to have been added to the iOS target?
I did not try iOS on Xojo more than easy tries … but I’m pretty sure you can do a lot of things with declares.
problem: you need to know how to write the declares, and for that you need to know objective C and XCode and its framework.
so the idea would be to do it in XCode, then immediately convert it to xojo declares, and then use it with Xojo.
but that is what ioskit (should) contain ?
there must some things you cannot do with declares, these things should be known and isolated and listed somewhere.
As far as I know they had hired Joe Strout to write the iOS version, he created a basic one, and then his contract was not extended. Your guess is as good as mine on why that was, or if anyone is actually working on it
full time or some time or as really needed for the current xojo / os version(s)
I don’t think this comment is fair.
When you read the Xojo release notes http://developer.xojo.com/release-notes last three releases have brought new features to iOS or at least support for the latest iOS SDK.
I think his statement is 100% fair. I just read thru the last 1/2 dozen release notes, and discounting fixes to “broken” items (Mojave/Xcode compatibily issue)… the only things I saw where “fixes” to iOSTable and HtmlViewer… Still limited support for important properties for existing controls, still many controls missing all together.
So my opinion (and perhaps that of Markus and others) is that the effort being expended is the minimum to keep what currently exists “working”, but no effort is being expended to improve the product…
I’ve done an iOS app for a client and they’re happy with it - we deploy using an Enterprise profile. I think the biggest challenge (at least for me as someone who firmly established in the desktop, console, and web Xojo applications) was the terminology change with iOS and the forced learning curve of the Xojo framework. Yes, you end up using a fair number of declares but there are Xojo iOS developers that can help out.
I don’t think Xojo for iOS is right for every project but then the same could be said for desktop, console, and web apps. It’s yet another tool in the arsenal and if Xojo can do it, great. If not, then you go to Xcode or something else.
Personally, I don’t think Xojo for iOS will be ‘good’ until there is an Android counterpart. At this point we have no idea when we’ll see Android but I think we can assume it won’t happen in 2018. And then when we do get it how limited will it be in first and second releases?
there is a mandatory fusion that must happen between iOS and Android for Xojo.
we must be able to reuse the code between the two, or there would be no xojo advantage.
and if this fusion also melt for other platform (with API 2.0 ?) it would be fantastic.
[quote=414798:@Jean-Yves Pochez]there is a mandatory fusion that must happen between iOS and Android for Xojo.
we must be able to reuse the code between the two, or there would be no xojo advantage.
and if this fusion also melt for other platform (with API 2.0 ?) it would be fantastic.[/quote]
Agreed. I’m willing to maintain two projects for mobile and desktop. I’m not willing to maintain projects for ios, android, and desktop. I’d prefer to maintain a single project with multiple user interfaces, though there’s very little chance of that happening. Similarly, I do not want any type of user interface sharing between mobile and desktop.
Just a reminder that promoting competitive tools (#9 and #13) in this forum is a violation of the forum guidelines. To that end, some comments/links have been removed. Thanks for understanding.
Lol, it is obvious that the compilation cant be done directly on the windows machine, but in the tool that I use (Not promoting competitive tools), you can make all the developping work, it just compiles remotely in a mac.
But as I said, in xojo, you cant even do the editing on windows.
I think that Xojo is more than capable of creating excellent iOS apps but just like the desktop version it’s a much better fit for some types of app than others.
I brought our business management iOS app in-house using Xojo, and the app that I built was a huge improvement on the one that an external developer wrote for us.
It is frustrating that a lot of the work that I put into porting our old framework code to the “new” framework isn’t going to be usable with Android, but I understand and accept that API 2.0 is going to be better for Xojo users in the long run. From what’s been said about the API 2.0 framework, I very much doubt that we’ll see any of the “new” framework deprecated on iOS within the next couple of years because Xojo have so many other priorities.
Why do you think iOS support won’t be good until we see Android support?
Only in that most clients I talk to want iOS and Android apps. So only being able to offer a Xojo solution for just iOS isn’t helpful. Android support will compliment iOS. Currently I can offer iOS but then I have to look for another solution for Android. Nothing bad about iOS now - it’s just missing the Android counterpart.
Sorry for my poor wording.
That’s an impressive looking piece of software (just watched the video on your site).
@Jeremie Leroy - you showed a nice sample how to use Regular Expressions in iOS with Jason Kings Library. Using the following Code returns all matches, but it match over the lines from the last to the first Array index, why? Does iOS RegEx matches in the opposite direction?
[code]Dim reg As New JKRegEx.RegEx
reg.SearchPattern = “(0|[1-9]+[0-9]) (@[^@]+@ |)([A-Za-z0-9_]+)( [^
\r]|)”
’ Initialize RegEx.
Dim myMatch As JKRegEx.RegExMatch
’ Split Text into lines.
Dim lines() As Text = MyContant.Split(&uA) ’ Text Constant with different lines
’ Loop through lines.
For i As Integer = 0 To lines.UBound
myMatch = reg.Search(lines(i))
If myMatch <> Nil Then
MessageBox1.Message = myMatch.SubExpressionString(1) + &uA _
+ myMatch.SubExpressionString(2) + &uA _
+ myMatch.SubExpressionString(3) + &uA _
+ myMatch.SubExpressionString(4)
MessageBox1.Show
End If
Next[/code]
I don’t have enough experience with regex overall to understand what your search pattern does and why it would match in the opposite direction, sorry.
You simply can use another easier pattern. I just wanted to know, if you or other users will also get the matches in upside down order when using JKRegEx.