Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-23570] Hyperloop: iOS - Support use_frameworks flag in Cocoapods

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2017-09-18T15:14:32.000+0000
Affected Version/sn/a
Fix Version/sHyperloop 2.2.0
ComponentsHyperloop, iOS
Labelshyperloop, notable, swift
ReporterRon Piwetz
AssigneeJan Vennemann
Created2016-06-22T15:35:36.000+0000
Updated2017-10-19T22:43:37.000+0000

Description

When use_frameworks! is included in Podfile, linking fails due to the framework being looked for in the wrong location. Even if the framework is placed in the expected location, the app will crash upon execution. Details provided below. I discovered this issue while trying to use a swift Cocoapod, but it is easily reproduced using the Hyperloop_Sample app as well. I will describe steps to reproduce for both cases. 1. For Hyperloop_Sample, simply add use_frameworks! to the beginning of Podfile and change the platform to 8.0 (frameworks only supported in iOS 8+). Change the min-ios-ver to 8.0 in tiapp.xml as well. As expected, instead of creating static libraries, frameworks for each pod are created instead. These can be seen inside of build/Release-iphonesimulator. The first issue comes during linking. The framework is expected to be at build/iphone/build/Products/Debug-iphonesimulator as seen in the attached build log (see Sample.log), search for GLCalendarView to see the expected location of the framework on line 4466. I then tried manually copying the 3 frameworks from build/Release-iphonesimulator to build/iphone/build/Products/Debug-iphonesimulator which allows the app to be built, but when it runs on the simulator, immediately crashes, see the attached crash log (Sample.crash). I'm not real sure what the problem is, just that the error is "Library not loaded" for reason "image not found". 2. Next, I created a new project, enabled hyperloop, then tried to use a swift cocoapod. Swift pods require use of use_frameworks!, so without this issue being resolved, we will be unable to use any swift pods. I've attached my Podfile (see Podfile). I tried building without referencing the pod in the Podfile, just to test, and while the app builds, it crashes as well, see (swift.crash).

Attachments

FileDateSize
Podfile2016-06-22T15:28:24.000+000091
Sample.crash2016-06-22T15:23:58.000+00004085
Sample.log2016-06-22T15:11:52.000+00002476353
swift.crash2016-06-22T15:34:15.000+000048981

Comments

  1. Hans Knöchel 2016-06-23

    Hey there! Please follow TIMOB-23530 for further discussions, we already a PR in place for the GA.
  2. Brenton House 2016-06-28

    [~hansknoechel] are we sure that the new ticket covers the scenario in this ticket?
  3. Hans Knöchel 2016-06-28

    Nope it doesn't, I just realized that today. Sorry for closing! And thank you [~rpiwetz] for noticing. We might want to open this one again and handle the issue here. Thanks again!
  4. Chee Kiat Ng 2016-07-21

    [~bimmel] May want to mention this somewhere as a known issue so that people know the current hyperloop module is not able to use swiftpods.
  5. Brenton House 2016-10-12

    [~hansknoechel] How does the timeframe for Hyperloop 2.0 align w/ the timeline for Appcelerator 6.0?
  6. Hans Knöchel 2016-10-12

  7. Jan Vennemann 2016-11-29

    A short status update about the current progress on this ticket: I was successfully able to prepare the Hyperloop build pipeline for Swift Pods by integrating a script from CocoaPods which embeds the Frameworks into the Xcode project and copies them over to their required destination. Currently there are two blockers for this ticket: * TIMOB-24163: If the framework requires Swift only classes/structs, the metabase generation fails. For example Alamofire requires the Swift-only struct URL * TIMOB-24180: Swift files that have references to each other can not be processed because the Swift metabase parser currently parses them file by file. Both issues can be resolved by using [SourceKit](https://github.com/apple/swift/tree/master/tools/SourceKit) but require a complete rewrite of the Swift metabase parser.
  8. Jan Vennemann 2017-03-03

    [~hansknoechel], to speed this up i would suggest to split the support for dynamic framework in two parts. In a first step we only support frameworks which expose an Objective-C interface. I have a PoC for that running and it requires no changes to the Swift metabase parser. After that we can focus on bringing support for pure Swift frameworks with the metabase parser rewrite. Thoughts?
  9. Jan Vennemann 2017-04-21

    PR: https://github.com/appcelerator/hyperloop.next/pull/159 This is the first iteration for support of dynamic frameworks with the use_framework! flag in CocoaPods. It is currently limited to frameworks that expose an Objective-C interface header, so not all Swift Pods are supported yet. To achieve that we first need to rewrite the Swift Metabase parser and evaluate a few other technical challenges. I'll create a few additional tickets dedicated to that soon and link them to this one.
  10. Jan Vennemann 2017-09-15

    [~hknoechel], updated the PR with the latest changes which means it now also resolves TIMOB-23853. Breakdown of important changes: - Allows usage of use_frameworks! flag in CocoaPods - Support of Swift frameworks if they provide an Objective-C interface header - Hyperloop now automatically picks up all frameworks from modules and the project's platform/ios folder. No manual configuration needed anymore for frameworks in appc.js.
  11. Jan Vennemann 2017-10-19

    [~ewieber], follow these steps to verify. They use they hyperloop-examples project.

    Add the use_frameworks! flag to the Podfile as well as pod 'AWSS3'

    Add the following code to app/controllers/index.js

        var AWSS3TransferManagerDownloadRequest = require('AWSS3/AWSS3TransferManagerDownloadRequest');
    var downloadRequest = new AWSS3TransferManagerDownloadRequest();
    downloadRequest.bucket = 'myBucket';
    *Expected behavior* The app should launch successfully. The above code is executed upon opening and makes sure the AWSS3 APIs are available, which come from a dynamic frameworks. The other third-party examples in the app should still work as expected.
  12. Eric Wieber 2017-10-19

    Verified. The use_frameworks! flag can be used in podfile without issue. Tested using the flag with dynamic frameworks and ensuring that their inclusion did not break other third-party frameworks in the project.

JSON Source