Signed App Issue

[Jon_Ogden]

I’ve sent Christian Schmitz and Sam Rowlands a joint email on this but figured I would ask here in case anyone has seen this as well.

I use Christian’s RegistrationMBS plugin for generating license codes for my app. I’m using AppWrapper4 to sign and notarize my app.

When I do this, it breaks my license key validation routine. So now people who upgrade my software get notices their license keys don’t work and any key that I generate again still fails. So I’m not quite certain what is going on.

I’m not entirely certain how to debug it as I can’t really sign and notarize a debug build. I suppose I could put some logging statements in, make a build and sign/notarize it and see what’s going on. But thought I’d ask if there’s some easy fix or something I am doing that is stupid.

I am not using any entitlements or preparing the app for the App Store. So nothing should be sandboxed. I store a file that contains the license key and user data in the /Library/Application Support directory. But I also keep the settings database for the app there as well and I have no issues accessing that. So I am kind of confused…

Has anyone else seen this?

[Thom_McGrath]

I have not seen it, but you can absolutely sign your debug builds. You could notarize too, using the “Run Paused” option in the IDE. It’ll do the build, then you notarize, and launch it manually. But notarization probably isn’t the cause, so I’d worry about getting your debug apps signed and see if that reveals anything.

[Christian_Schmitz]

You may want to write all parameters to a log file.
Maybe one of the values is different or has different bytes or text encoding.
A little change in behavior for code signed app may cause trouble.

[Greg_O_Lone]

@Jon_Ogden

I’m not entirely certain how to debug it as I can’t really sign and notarize a debug build.

Have you “Run Paused” and then tried signing and notarizing while the IDE is waiting and then launching the notarized app afterwards?

[Jon_Ogden]

I know about Run Paused, but I was not aware that I could sign and notarize a debug build.

[Beatrix_Willius]

Without codesigning in the debugger I can’t do full hard disk access or AppleScript. I think Christian has the best idea for checking.

[Jon_Ogden]

Well using RunPaused I was able to sign my debug app. There was no issue. Everything ran fine. So that did not help. I’ll need to add logging as Christian suggested.

[Jon_Ogden]

OK. I figured this out. Now I don’t know how to solve it…This may be one for @Sam_Rowlands or maybe it’s a Xojo issue.

Here is the code where I set up my RegistrationEngineMBS:

Dim MyReg As  RegistrationEngineMBS
MyReg = New RegistrationEngineMBS
MyReg.Mode = 1
MyReg.Prefix = "MS4"
MyReg.Field(0) = Trim(RegName)  // User Name
MyReg.Field(1) = Trim(RegEmail)  // User Email
MyReg.Field(2) = LeMachine 'CalculateID(0)  //CalculateSystemCode
MyReg.Field(3) = Version  // Version Being Registered
MyReg.Field(4) = Str(App.MajorVersion)
MyReg.Field(5) = "526642367520044270651015"
MyReg.BlockLength = 4
MyReg.NumberLength = 16 

MyRegField(4) is where the change is between signed and unsigned apps.

In the unsigned app, App.MajorVersion is reporting as 4 which is correct.

In the signed app, App.MajorVersion is reporting 596 which is the build number.

So why would the framework return a build number instead of the MajorVersion number?

That’s the issue.

[Beatrix_Willius]

How do you codesign your app? Is there anything on the build number in the script?

[Jon_Ogden]

OK. I found the solution. According to AppWrapper Docs, here is what happens when you set the version formatting to the “Apple” format:

Apple Format

Reformatted to Apple’s recommended format for both channels.

Example		1.2.3.4.5
app.version	=	1.2.3
app.major	=	5
app.minor	=	0
app.bug	=	0
app.stage	=	0
app.nonReleaseVersion	=	0
app.infoVersionString	=	1.2.3 (5)
app.infoBuildVersion	=	5

So in the Apple formatting of version strings, for some reason App.Major is reported as the build number! @Sam_Rowlands why is that? Doesn’t make sense?

Since I’m not going to be releasing my app in the store, I don’t need this formatting so I can go back to AutoTrim which should leave it untouched…

[Christian_Schmitz]

Great you found it.

[Jon_Ogden]

Yep. That worked. Would never have expected signing to change the App.MajorVersion number…

[Sam_Rowlands]

@Jon_Ogden

So in the Apple formatting of version strings, for some reason App.Major is reported as the build number! @Sam_Rowlands why is that? Doesn’t make sense?

Because Xojo store the version number major.minor.bug.stage.nonrelease in the field where Apple expects it to contain just nonrelease.

By default AW will “auto-trim” which means it won’t touch the version for Web distribution. But for the App Store, it will trim it to major.minor.bug as that is tolerated on the App Store.

There are other places where Xojo could store the entire version number in the format they like, which wouldn’t be affected by making this value conform to the App Store shenanigans. I can even help Xojo if they’d like.

[Jon_Ogden]

I understand that it’s different. But major version is recognized by everyone as the first item. So app.major version should always return the first digit(s) of the version string. I understand if Bug/Build get intertwined. No problem. I learned that with iOS. But the Major and Minor should not be touched.

[Sam_Rowlands]

Jon,
I should have said this in my first response, I am sorry that it caused you complications and wasted time. Over the years I’ve been trying to think of ways to make this solution clearer.

@Jon_Ogden

I understand that it’s different. But major version is recognized by everyone as the first item. So app.major version should always return the first digit(s) of the version string. I understand if Bug/Build get intertwined. No problem. I learned that with iOS. But the Major and Minor should not be touched.

This is where the two formats really differ as projects made with Apple’s tools only store the build/non-release in that field. The rest is stored in a different field of the plist. Apple expects apps made with other tools to conform, thankfully they do tolerate a compromise.

Hence the Auto-trim and Always-trim option, which will work as you expect, but at the loss of the stage code and non-release version.

I think what might help is if Xojo were to store the version number in the executable file, Xojo already create the entry but leave it set to 0.0.0.0.0. If they stored the version there and read the version from there when you call app.major, app.minor, etc it wouldn’t matter how the version number is formatted in the info.plist file.

I can force the version number into this field, however you’d need to use different code to read it from this field.

[Greg_O_Lone]

Storing it in the app would mean that you can’t change it without a complete rebuild though and if all you were changing was a license agreement you might not want to do that. For instance, a ground-up rebuild of the IDE takes 3.5 hrs, but just replacing a single file, updating the plist, signing and notarizing takes about 20 minutes.

[Sam_Rowlands]

It is a conundrum that we could work together to solve.

[Jon_Ogden]

I never had any idea that the version information was not stored as part of the binary.

[Jon_Ogden]

Thank you for the explanation, Sam.

[Jon_Ogden]

So @Sam_Rowlands and @Greg_O_Lone,

As I thought about this some more… Why does the Xojo iOS (or should I say Mobile) Framework not have this issue? Xojo signs the app and the version numbering is all seen as fine by Apple. Why can’t a similar solution be employed by the desktop? I think between Xojo and Ohanaware, this should be fixable…