Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ios): xcode 11 / ios 13 compatiility #325

Merged
merged 4 commits into from Sep 10, 2019

Conversation

janvennemann
Copy link
Contributor

@janvennemann janvennemann commented Sep 2, 2019

Building the Pods project with xcodebuild from Xcode 11 fails if project.xcworkspace/contents.xcworkspacedata is not present. This will generate the file if required to ensure compatibility with Xcode 11.

Closes TIMOB-27362

Copy link
Contributor

@vijaysingh-axway vijaysingh-axway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@janvennemann janvennemann changed the title fix(ios): xcode 11 compatiility fix(ios): xcode 11 / ios 13 compatiility Sep 4, 2019
@lokeshchdhry
Copy link
Contributor

@sgtcoolguy , we are waiting for few last fixes from Jan for this & a hyperloop module to test.

@janvennemann
Copy link
Contributor Author

@sgtcoolguy so this got way bigger than expected. I tried to fix some generics handling at first but our metabase parser has a really unbelievably crappy and fragile design so it turned out that i had to go down the rabbit hole to fix any of this.

We used to have a very basic generic type handling, which was pretty much hardcoded to the commonly used template params ObjectType and KeyType that Apple uses. Now that worked fine until in iOS 13 a few of those were introduced in blocks which completely blew up our block processing (which is based on processing the block signature as a string without any clang context available). Well, long story short, i had to fix a few things to get this mess somewhat stable again:

  • Blocks will be properly parsed with libclang now, except for block return values. I couldn't find out how this is done with the C API, so this still used the old style string signature processing.
  • All typedefs will be resolved to their underlying type, including template parameters (one exception is instancetype which we need to detect init methods).
  • Encoding will be resolved directly in most cases via the appropriate libclang APIs.

When we are going to move Hyperloop to the core we should really consider switching to the C++ API of clang for the metabase parser.

@janvennemann
Copy link
Contributor Author

@lokeshchdhry Please check the 4.0.4 Beta 1 release.

Also note that the hyperloop-examples project needs some changes because the GLCalendarView seems to be incompatible with Xcode 11 / iOS 13. For testing the changes in this ticket remove GLCalendarView from the Podfile and comment out the content of app/controllers/ios/libraries/calendar.js and app/lib/ios/subclasses/calendardelegate.js

@longton95
Copy link

FR Passed

Tested with the hyperloop example app, the application built successfully.

Test Environment

MacOS Mojave version 10.15 beta
Xcode 11 beta 6
Node 10.13.0
iPhone 8 plus sim (13.0), iPhone 6 plus (12.4), iPhone 7 (13.0)
NPM 4.2.14
CLI 7.1.1
SDK 8.2.0.v20190906140307

Waiting on second CR for merge

Copy link
Contributor

@vijaysingh-axway vijaysingh-axway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@lokeshchdhry lokeshchdhry merged commit 8256187 into tidev:master Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants