/cc @hyangah

Any update on this? We're currently blocked to release an update to Testflight due to this issue. I'm going to try to downgrade to xcode 10.1 to work around the issue for now (see: https://stackoverflow.com/questions/14756026/how-to-downgrade-xcode-to-previous-version). Thanks

More research seems to indicate it is actually go 1.12 that introduces this failure, my hunch is changes related to: #17490

Possibly related:

• go 1.12 binaries rejected from mac app store due to ___getdirentries64 #30933
• syscall: darwin arm{,64} libSystem syscalls are not compliant with the App Store submissions  #28984
• go 1.12 binaries rejected from mac app store due to ___getdirentries64 [1.12 backport] #31244

Do you know of documentation about when ptrace is allowed?
I suspect it is ok on OSX but not on iOS. (The manpage on my 10.12 OSX box doesn't mention anything about disallowed/deprecated/...)

It's pretty easy to rip out ptrace support, and we can do that because it is package syscall. The stdlib itself doesn't use ptrace. That said, I'd rather not break people's programs unnecessarily.

I can confirm releasing to Testflight worked again with go@1.11.6, gomobile@ 3e0bab5405d63a8f5dd9d9764a24c8e5ac4997fa, xcode@10.2.1.

@randall77 Tried to find any documentation on this, but to no luck.

Maybe best bet is to disable it, then check if that's enough for the app to pass App Store review? I think people's programs are broken already, if they want it on the App Store that is...

Any progress on this?
It may need to be back ported go 1.12 if a fix is found, since it renders Go 1.12 unusable in a mobile scenario.
cc @eliasnaur if he has an idea ?

I think the way forward is to disable ptrace in package syscall. It should be easy because the runtime doesn't depend on it according to Keith. And then, test it in Testflight or App Store.
I don't have a paid apple dev account so I can't do it.

I'm hoping to push a quick fix to the app store with the ptrace package disabled. Any guidance on disabling it would be appreciated! I'm taking some blind stabs now.

I've shamelessly removed ptrace from the syscall package here: https://github.com/textileio/go/tree/sander/ptrace-hackery

Our framework is being built with it in CI here: https://github.com/textileio/go-textile/blob/master/.circleci/config.yml#L186

I'll report back when we know whether or not Apple is happy with it.

thanks @sanderpick !

I'm happy to report that Apple has accepted the build 🎉. Thanks for the suggestion @eliasnaur.

Great! Can you send a CL with your changes so the fix can be included in Go 1.13?

Marking as Go 1.13 because this needs to go into the go standard library, not gomobile.

Here's a comparison (changes added on top of go1.12.5 tag): https://github.com/textileio/go/compare/3a1b4e7..ef7e9bd

Since this is just an issue with the app store, maybe a flag or env var with gomobile could be used to indicate to go that it ought to strip ptrace from the syscall package... ?

I think it is better to change syscall.Ptrace to always return an error (for example syscall.ENAVAIL) on darwin/arm and darwin/arm64, leaving darwin/386 and darwin/amd64 alone.

Note that you can submit your changes as a Github pull request.

I think it is better to change syscall.Ptrace to always return an error

Would this remove the reference from the syscall trampoline, though? The App store complains about it if it is present at all. It's not a dynamic analysis if it is actually called or not.

Sure, the trampolines and libc references need to go as well. They are already gone with @sanderpick's changes; I merely suggested the GOARCH dependent approach.

Change https://golang.org/cl/182297 mentions this issue: syscall: disable ptrace on iOS

Change https://golang.org/cl/182317 mentions this issue: unix: disable ptrace on iOS

I was too slow... thanks for tackling this @eliasnaur!

Thanks a lot!