I've been struggling with the same issue for the last 3 days. If I update appcenter packages to v4 I can't build my iOS app.

The biggest problem I see with overloading [] is that it normally returns element of list, while here it will change return type drasticly. Something like array[[1..5]], or object[['x'..'z']] would be nice, but it's obviously too ambiguous.

Description

On one of the android applications, I ran into a problem. The event list is empty. The page displays the content "Everything is ready to track your app's usage." However, when I go to the "Log flow" page, I clearly see the event flow.

Repro Steps

It `s Magic. I tested my code on other appcenter applications by changing the "appSecret" and the events worked fine.

Details

"dependencies": { "@react-native-community/async-storage": "1.7.1", "@react-native-community/blur": "^3.6.0", "@react-native-community/checkbox": "^0.5.0", "@react-native-community/geolocation": "^2.0.2", "@react-native-community/masked-view": "0.1.6", "@react-native-community/picker": "^1.6.6", "@react-native-community/push-notification-ios": "^1.4.0", "@react-native-community/viewpager": "^4.1.4", "@react-native-firebase/app": "^8.3.1", "@react-native-firebase/messaging": "^7.7.2", "@react-navigation/bottom-tabs": "^5.6.1", "@react-navigation/native": "5.6.1", "@react-navigation/stack": "5.6.2", "@types/yup": "^0.26.30", "appcenter": "^3.0.3", "appcenter-analytics": "^3.0.3", "appcenter-crashes": "^3.0.3", "formik": "2.1.4", "i18next": "19.1.0", "intl": "^1.2.5", "libphonenumber-js": "^1.7.54", "lodash": "^4.17.19", "lottie-ios": "3.1.3", "lottie-react-native": "^3.4.0", "moment": "^2.27.0", "moment-timezone": "^0.5.31", "react": "16.9.0", "react-i18next": "11.3.2", "react-native": "0.61.5", "react-native-android-location-enabler": "^1.2.1", "react-native-bootsplash": "^2.2.5", "react-native-code-push": "^6.3.0", "react-native-config": "^0.12.0", "react-native-confirmation-code-field": "^6.4.0", "react-native-device-info": "^7.3.1", "react-native-geocoding": "^0.4.0", "react-native-gesture-handler": "^1.6.1", "react-native-google-places-autocomplete": "^1.8.0", "react-native-image-crop-picker": "^0.35.0", "react-native-keyboard-aware-scroll-view": "^0.9.2", "react-native-maps": "0.27.1", "react-native-markdown-display": "^6.1.6", "react-native-modal": "^11.5.6", "react-native-permissions": "^2.1.5", "react-native-phone-input": "^0.2.4", "react-native-picker-select": "^8.0.0", "react-native-push-notification": "^5.0.1", "react-native-reanimated": "^1.9.0", "react-native-safe-area-context": "^3.0.7", "react-native-safe-area-view": "^1.1.1", "react-native-screens": "2.0.0-beta.2", "react-native-scrollable-tab-view": "^1.0.0", "react-native-share": "^3.7.0", "react-native-size-matters": "^0.3.0", "react-native-svg": "^12.1.0", "react-native-version-check": "^3.4.1", "react-native-webview": "^10.3.2", "react-redux": "7.1.3", "reanimated-bottom-sheet": "^1.0.0-alpha.20", "redux": "4.0.5", "redux-act": "1.7.7", "redux-persist": "6.0.0", "redux-saga": "1.1.3", "reselect": "4.0.0", "socket.io-client": "^2.3.0", "yup": "0.28.1" }, 2. Which OS version did you experience the issue on? - Android 10 3. What device version did you see this error on? Were you using an emulator or a physical device? - e.g. Google Pixel 2 emulator, iPhone X physical device 4. What third party libraries are you using? - example 5. Run the following command and paste the output below: react-native info

System: OS: macOS 11.1 CPU: (4) x64 Intel(R) Core(TM) i5-4288U CPU @ 2.60GHz Memory: 302.95 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 12.18.2 - /usr/local/bin/node Yarn: 1.22.10 - /usr/local/bin/yarn npm: 6.14.5 - /usr/local/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 14.3, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2 Android SDK: API Levels: 23, 24, 25, 26, 27, 28, 29, 30 Build Tools: 26.0.2, 27.0.3, 28.0.2, 28.0.3, 29.0.2, 30.0.2, 30.0.3 System Images: android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom IDEs: Android Studio: 4.1 AI-201.8743.12.41.6858069 Xcode: 12.3/12C33 - /usr/bin/xcodebuild npmPackages: react: 16.9.0 => 16.9.0 react-native: 0.61.5 => 0.61.5 npmGlobalPackages: react-native-cli: 2.0.1

6. If you're developing for React Native iOS, run the following command and paste the output below: pod --version

1.9.1

Event started working normally

@pepibumur idea is pretty cool, but my concern is can a manifest file satisfy all use cases provided by Xcode and gradle like Build Settings, Build Phases, custom gradle tasks etc. What if someone needs to do something not supported by the manifest file? I think the user then have to edit the generated xcode files and commit the same. With so much options provided by xcode and android build system managing everything under a single manifest file will be a nightmare or impossible I think.

I went through tuist, looks like it has some learning curve which will be only be familiar to someone from iOS background, for pure JS developers looks like the learning curve will be high.

Hi Appcenter team,

I am getting the error while using Xcode 11.4.1 in the integration of Appcenter SDK in React Native Project

AppCenter/MSAppCenter.h' file not found

React Native Info: System: OS: macOS 10.15.7 CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Memory: 602.35 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 12.18.3 - /usr/local/bin/node Yarn: 1.22.5 - /usr/local/bin/yarn npm: 6.14.6 - /usr/local/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 14.0, DriverKit 19.0, macOS 10.15, tvOS 14.0, watchOS 7.0 IDEs: Android Studio: 4.0 AI-193.6911.18.40.6514223 Xcode: 12.0.1/12A7300 - /usr/bin/xcodebuild npmPackages: react: 16.9.0 => 16.9.0 react-native: ^0.61.5 => 0.61.5

Cocoa Pods Info: 1.8.3

Steps Followed to resolved the issue:

1. Deleted node_modules folder
2. Integrated yarn install again
3. Re-Installed the pods
4. Clean Xcode Build
5. Delete Derived Data

Note: This was working and suddenly stopped working today.

App url https://appcenter.ms/orgs/haulwithus/apps/Haul-3

The tool would generate a standard project that you can edit as you'd edit the project that is currently part of the repository.

I would assume that the project it generates wouldn't really be editable, or at least it would get blown away the next time it was generated. So you'd have to figure out how to modify the React Native specific upstream configuration files in the way you want to be able to generate the downstream native project. Is that right?

FWIW, that's how we operate at Facebook. We define everything in buck, and buck project generates local Xcode and Android studio projects that we use for debugging and working in the native editor. https://buck.build/command/project.html

If we build something custom that would greatly increase the surface area of React Native (even though it wouldn't be maintained by us at FB). There would probably end up needing to be a team that owned this to make it successful and keep it well documented.

Would that surface increase if something like this was built into the React Native CLI?

It would, wouldn't it? I would expect it would increase the surface area of the CLI and the burden on Callstack to maintain it.

Are there any roadblocks to prototyping / building this out? If Shopify is interested in building this, would it be reasonable to build it as a separate project initialization approach and if it works out and the community prefers it, then in the future we could look at switching the default?

Are there pieces you think are currently in the initialization path that make it harder for something like this to be built separately?

<speaking from a React Native Windows + Windows perspective>

If I understand the proposal, this is describing a meta-project; you write the project spec and then some tool will generate the appropriate platform-specific / build system-specific projects/solutions. For example, on Windows this would generate the right vcxproj/csproj/sln files.

I think that approach would work fine for someone who is completely oblivious to the native code, someone coming from a pure JS background and just wants to use "good defaults" (it's not clear that there is a one-size-fits-all).

Adding the logic to the RN CLI would only take care of the in-tree platforms, but would leave out-of-tree platforms like Windows and macOS, to implement and maintain the logic to generate projects themselves.

On Windows we have apps that are going to be a mix of React Native and other technologies (XAML, etc.). The way this works today is when you create a react native windows app, a solution is generated (which describes a collection of projects), and a language specific project is also generated (C++ or C# depending on what the user chooses). From that point onwards, RNW is out of the picture for the most part when it comes to project management. We do perform some tasks for autolinking etc. but those are heuristic based since the projects can be manually edited/changed to best suit the developer's needs.

I'm not sure what all react-native edit ios does, does it just open the project file in an editor?

</>

I transpile to js, (from parenscript if you care) and there I use a transform into React.createElement which makes me interested in the new transform in React 17 (mentioned here).

That, in turn, links to a file not in master, but that file is written in the form of a proposal, and it's not clear whether it represents the final details.

Is there another document with the details?

that's why I said to submit a PR and not open an issue

A concern I have is that this would make things more friendly for JS engineers but more hostile to engineers with a native background. I worry they won't recognize the projects, and React Native will feel even more like a black box, making those engineers even more resistant to it. In recent history, the React Native team has been kinda pushing the other direction to make things more familiar to native engineers (but maybe at the cost of our current user base).

Interesting, what do you think this would make the tool hostile for engineers with a native background? The tool would generate a standard project that you can edit as you'd edit the project that is currently part of the repository. The workflows that I was thinking about are:

• I'm a developer and want to work on the app (Javascript side): I run react-native run ios and I get my app up and running with the Metro server.
• I'm a developer that wants to edit the native code/project: I run react-native edit ios and I get the Xcode project opened and ready to interact with it. I can build it, run native tests...

One of the other benefits of our current approach of leaning on the native experience has been that when issues come up, you can go look at the Xcode or Android documentation.

Right, but in our experience, those projects quickly become a source of complexities and inconsistencies that inevitably lead to compilation issues. I think this is the result of:

• Changes in projects usually disregarded when reviewing PRs.
• Package integration steps followed without really understanding what they are for.
• Solving compilation issues by applying random responses found on Stackoverflow.

This is also solvable by adding more linting on our side (e.g. running a git hook or a pipeline on CI), or ensuring that developers have a good understanding of the native pieces before they introduce changes, but we think the developer experience will be better if we minimize the native surface developers are exposed to and expose as much internals as needed.

If we build something custom that would greatly increase the surface area of React Native (even though it wouldn't be maintained by us at FB). There would probably end up needing to be a team that owned this to make it successful and keep it well documented.

Would that surface increase if something like this was built into the React Native CLI?

Also, what you are describing sounds very similar to Expo managed projects. What do you see as the difference between this approach and the space that Expo is supporting?

Unlike Expo that has the concept of "ejecting", which takes you from we own the native project to you are the owner of the native projects, the native projects are generated when needed. Pretty much like how CocoaPods does with dependencies with native code when we need to build the native project, we need CocoaPods to generate an Xcode project that contains the build instructions for xcodebuild to be able to link the code of that dependency. Take that approach and expand it to your own project too.

ok, I'll add it there, but it seems very clear on that repo that only bug reports should be posted.