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

Missing .xcodeproj for iOS projects #30196

Closed
rumax opened this issue Oct 16, 2020 · 16 comments
Closed

Missing .xcodeproj for iOS projects #30196

rumax opened this issue Oct 16, 2020 · 16 comments
Labels
Needs: Issue Manager Attention Platform: iOS iOS applications. Stale There has been a lack of activity on this issue and it may be closed soon.

Comments

@rumax
Copy link
Contributor

rumax commented Oct 16, 2020

Description

During upgrade the project from react-native 0.60.* to react-native c it was observer that react native does not have *.xcodeproj files anymore. That make it impossible to use the latest and greatest react native in project that uses Carthage. There is also nothing about it in docs. For example, https://reactnative.dev/docs/integration-with-existing-apps says that CocoaPods are needed, but that is not an option for existing projects that uses Carthage. Same for https://reactnative.dev/docs/upgrading.html, it does not cover this case.

As a result migration to the latest react native is blocked:

Screenshot 2020-10-16 at 00 13 51

React Native version:

System:
    OS: macOS 10.15.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Memory: 6.23 GB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.16.1 - ~/.nvm/versions/node/v12.16.1/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.1/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.16.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 26, 27, 28, 29
      Build Tools: 27.0.3, 28.0.3, 29.0.2, 29.0.3, 30.0.2
      System Images: android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.0 AI-193.6911.18.40.6626763
    Xcode: 11.3.1/11C505 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_242 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1 
    react-native: 0.63.3 => 0.63.3 
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

  1. Use existing project with Carthage
  2. Try to integrate react native to this project

Or

  1. Use existing react native project with Carthage with RN version <= 0.60.*
  2. Try to upgrade react native to this project

Expected Results

Snack, code example, screenshot, or link to a repository:

Not needed

Additional information

According to official RN documentation linking-libraries-ios

If the library has native code, there must be an .xcodeproj file inside its folder. Drag this file to your project on Xcode (usually under the Libraries group on Xcode);

it is also clearly stated that there must be an .xcodeproj and this is how iOS development happens.

@sanderfrenken
Copy link

To elaborate a bit, by removing the .xcodeproj files manual linking of react-native has become AFAIK close to impossible. The only way I can think of now is by creating references from all the react-native sources in node_modules in the consuming project. This however is a cumbersome job and in addition very error prone (think of missed files, or adding sources that are only needed for testing to the actual build target).

By disabling manual linking, the only way for any project to use react-native seems to be by using CocoaPods.
IMO, this is not a solution that fits all.

There are many existing projects that rely heavily on Carthage for example, or SPM.

By forcing CocoaPods, one can only decide to either use both CocoaPods and the other dependency manager (welcome trouble, this is definitely not advisable nor maintainable) in the same project, or migrate the complete project to CocoaPods. But the latter is not even always possible, as for example some specific dependencies might not be available using CocoaPods.

I am very curious if there is another way of using the latest react-native in a project while not using CocoaPods.

@suwu150
Copy link

suwu150 commented Oct 18, 2020

I also hope to be able to provide a solution, without the help of any third-party management, to directly deal with project dependencies. I encountered a situation where cocoapods cannot be used in the project, and I need to deal with it urgently.

The react-native version I currently use is 0.62.0, if I can't find a solution, I can only fall back to version 0.59.10
@sanderfrenken

@rectified95
Copy link

rectified95 commented Oct 20, 2020

Thanks for describing your pains points with the upgrade to latest. Still, this is not strictly a new functionality regression. Please recreate this issue in the upgrade-support repo, as indicated by the issue templates:
https://github.com/react-native-community/upgrade-support

@rumax
Copy link
Contributor Author

rumax commented Oct 20, 2020

@rectified95 Can you please elaborate more why do you think it is upgrade issue? Because it is not: the same issue you will get in a new/existing project which does not support pods.

According to official RN documentation linking-libraries-ios

Did you also read this comment? This is official documentation and it clearly says: If the library has native code, there must be an .xcodeproj file inside its folder., so that issue is still valid as long as this documentation exists.

Moreover it is an issue for native project without cocoapods which could benefit from integrating RN into it, but you just killed that possibility by closing the issue and ignoring support.

@suwu150
Copy link

suwu150 commented Oct 23, 2020

react-native-community/upgrade-support#102

@rectified95
Copy link

rectified95 commented Oct 23, 2020

My impression was that you were trying to leverage patterns that used to work in a previous release and use them in a newer version of RN - that's what made me classify the issue as an upgrade problem.

Do note that there are around 800 open issues, and in order to keep it manageable, proper redirection to eg. the Proposals/Upgrade repo helps achieve that. Also, note that I suggested opening the issue in another repo, rather than saying it was going to be ignored - thanks for creating it there.

I'm reopening this issue, and tagging it for further investigation, and will let my colleagues decide which of the 2 issues to track this with.

@rumax
Copy link
Contributor Author

rumax commented Oct 25, 2020

react-native-community/upgrade-support#102

That's only part of the problem, but do not try to looks at it only from the upgrade side (which is a pain for a lot of projects of course). Looking at React v17.0 release, there is a good statement:

It also makes it easier to embed React into apps built with other technologies.

So in web they take care about other technologies and make it possible to embed the app. Why it is different in React native?

You can also look at it from another point of view: it is not a secret that there are at least 2 dependency management on iOS: Carthage and Pods. By forcing new project to use Pods maybe is not so bad (except that there are some downsides of that solution which is not a scope of the discussion), but for existing projects it is definitely not. Just think about a case: Some company has native iOS and native Android application, you as a developer, lead, architect or a consultancy company decide that the company can benefit from React Native and want to migrate their projects to RN. Of course you can rewrite everything at once, which will require a lot of resources and time. Or you can do a POC to convince that React Native is a right tool for that and will work to cover all business needs and do the work gradually. For that you can start with integration with Existing Apps, which of course requires Install CocoaPods step and which is not require/can be skipped for Carthage projects, if you have .xcodeproj files. That's why if you have a big project with Carthage, you will fail with React Native. And that's why my proposal was to:

#25583 pull request is reverted

which can easily fix that problem. Or find a better solution together and make React Native compatible with other technologies, just like React does.

@suwu150
Copy link

suwu150 commented Oct 26, 2020

https://reactnative.dev/docs/integration-with-existing-apps#3-install-cocoapods
the document has the following description:
image

Hope to improve the document, convenient for developers to use.

@suwu150
Copy link

suwu150 commented Nov 2, 2020

Can you give a solution or a feasibility plan? Or estimate the time for the solution, so that the next step can be planned

@jacksbox
Copy link

@suwu150 did you discover a solution? having the same problem...

@suwu150
Copy link

suwu150 commented Mar 31, 2021

@suwu150 did you discover a solution? having the same problem...

@JacksonGL I lowered the react-native version. .

@chsa911
Copy link

chsa911 commented Apr 15, 2021

I have also the problem of missing.xcodeproj file and to use xcode and cocoapods which is impossible as I cannot run pod init

@dehlen
Copy link
Contributor

dehlen commented Apr 20, 2021

I am also very interested in a solution to use RN with a different dependency manager than Cocoapods. In my case I‘d like to cache RN instead of recompiling it all the time and something like Carthage support would definetly help in this scenario.

@Nicholson85
Copy link

Nicholson85 commented Jun 4, 2021

Are there no further developments here. It seems crazy to omit these files from the libraries given the impact this is causing.

This also invalidates the underlying documentation.

@github-actions
Copy link

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Aug 22, 2023
@github-actions
Copy link

This issue was closed because it has been stalled for 7 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Issue Manager Attention Platform: iOS iOS applications. Stale There has been a lack of activity on this issue and it may be closed soon.
Projects
None yet
Development

No branches or pull requests

9 participants