Ios config #2490
Ios config #2490
Conversation
|
Warning Rate limit exceeded@Mozart299 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 14 minutes and 0 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis update makes several configuration and file management improvements. The changes include updating ignore rules, revision tracking, and build configurations for both Android and iOS platforms. New files such as Dart analysis options and Android’s MainActivity have been added, while auto-generated plugin registrant files and legacy build scripts have been removed. Additionally, iOS settings have been updated with modifications to the Podfile, Xcode project files, and asset configurations, along with introducing a basic widget test. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant MainActivity
participant FlutterEngine
User->>MainActivity: Launch the app
MainActivity->>FlutterEngine: Initialize engine and load configurations
FlutterEngine-->>MainActivity: Confirm initialization and load Flutter app assets
Note over FlutterEngine, MainActivity: Plugin registration is now handled differently due to removed registrant files
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
mobile-v3/test/widget_test.dart (1)
14-29: Consider expanding test coverageWhile the counter test is a good starting point, consider adding more test cases:
- Test edge cases (e.g., maximum counter value)
- Test other widget interactions
- Test widget initialization states
Would you like me to provide examples of additional test cases?
mobile-v3/analysis_options.yaml (1)
23-25: Consider enabling additional lint rulesThe commented examples show how to customize rules. Consider enabling:
prefer_single_quotesfor consistent string literals- Additional rules for null safety
- Performance-related lints
Would you like me to provide a list of recommended lint rules for your project?
mobile-v3/android/app/build.gradle.kts (1)
33-39: Build Types ConsiderationThe release build type currently uses the debug signing configuration, as indicated in the comments. While this can be acceptable during initial testing, it’s advisable to set up a dedicated and secure signing configuration for production releases.
mobile-v3/.gitignore (1)
70-71: Podfile.lock Exclusion ConsiderationWhile ignoring
/ios/Podfile.lockcan be appropriate for library projects, iOS applications typically benefit from committing the Podfile.lock to maintain consistent dependency versions across environments. Please verify that excluding this file aligns with your team’s workflow and release strategy.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
mobile-v3/android/gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jarmobile-v3/ios/Podfile.lockis excluded by!**/*.lockmobile-v3/ios/Runner/Assets.xcassets/LaunchBackground.imageset/background.pngis excluded by!**/*.pngmobile-v3/pubspec.lockis excluded by!**/*.lock
📒 Files selected for processing (21)
mobile-v3/.gitignore(2 hunks)mobile-v3/.metadata(2 hunks)mobile-v3/analysis_options.yaml(1 hunks)mobile-v3/android/app/build.gradle.kts(1 hunks)mobile-v3/android/app/src/main/java/io/flutter/plugins/GeneratedPluginRegistrant.java(0 hunks)mobile-v3/android/app/src/main/kotlin/com/airqo/airqo/MainActivity.kt(1 hunks)mobile-v3/android/gradlew(0 hunks)mobile-v3/android/gradlew.bat(0 hunks)mobile-v3/android/settings.gradle.kts(1 hunks)mobile-v3/ios/Flutter/Generated.xcconfig(0 hunks)mobile-v3/ios/Flutter/flutter_export_environment.sh(0 hunks)mobile-v3/ios/Podfile(2 hunks)mobile-v3/ios/Runner.xcodeproj/project.pbxproj(13 hunks)mobile-v3/ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme(1 hunks)mobile-v3/ios/Runner/AppDelegate.swift(1 hunks)mobile-v3/ios/Runner/Assets.xcassets/LaunchBackground.imageset/Contents.json(0 hunks)mobile-v3/ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json(1 hunks)mobile-v3/ios/Runner/GeneratedPluginRegistrant.h(0 hunks)mobile-v3/ios/Runner/GeneratedPluginRegistrant.m(0 hunks)mobile-v3/ios/Runner/Info.plist(1 hunks)mobile-v3/test/widget_test.dart(1 hunks)
💤 Files with no reviewable changes (8)
- mobile-v3/ios/Runner/GeneratedPluginRegistrant.h
- mobile-v3/ios/Flutter/flutter_export_environment.sh
- mobile-v3/ios/Flutter/Generated.xcconfig
- mobile-v3/ios/Runner/Assets.xcassets/LaunchBackground.imageset/Contents.json
- mobile-v3/android/gradlew
- mobile-v3/android/gradlew.bat
- mobile-v3/ios/Runner/GeneratedPluginRegistrant.m
- mobile-v3/android/app/src/main/java/io/flutter/plugins/GeneratedPluginRegistrant.java
✅ Files skipped from review due to trivial changes (3)
- mobile-v3/android/app/src/main/kotlin/com/airqo/airqo/MainActivity.kt
- mobile-v3/ios/Runner/Info.plist
- mobile-v3/ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json
🔇 Additional comments (15)
mobile-v3/.metadata (2)
7-7: Revision update looks good!The Flutter SDK revision has been consistently updated across both the main revision and root platform configuration.
Also applies to: 16-17
18-20: Verify macOS platform additionThe addition of macOS platform configuration suggests a shift in development focus. Please ensure this aligns with the project's cross-platform strategy, especially given the PR title "Ios config".
Could you clarify if the removal of iOS platform configuration and addition of macOS platform configuration is intentional?
mobile-v3/test/widget_test.dart (1)
11-11: Verify import path correctnessThe import path
package:airqo/main.dartassumes a specific package name. Please ensure this matches your pubspec.yaml configuration.mobile-v3/android/settings.gradle.kts (2)
2-8: LGTM! Robust Flutter SDK path handlingThe implementation properly validates the Flutter SDK path from local.properties with appropriate error messaging.
20-22:❓ Verification inconclusive
Verify plugin versions compatibility
Please verify the compatibility of these plugin versions:
- Flutter plugin loader: 1.0.0
- Android application: 8.7.0
- Kotlin Android: 1.8.22
🌐 Web query:
What are the latest stable versions of Android Gradle plugin and Kotlin Android plugin that are compatible with Flutter?💡 Result:
The latest stable versions of Android Gradle Plugin (AGP) and Kotlin Android Plugin compatible with Flutter projects are:
Android Gradle Plugin
- Latest Stable: 8.x (specifically 8.X.X)
- Requires Gradle wrapper version ≥8.X.X ([source][1][9][4])
Kotlin Android Plugin
- Minimum Required: 1.X.X
- Recommended Stable: 2.X.X ([source][3][4][6][8])
Compatibility Details
Component Version Range Notes Android Gradle Plugin 7.X–X.X Tested with Flutter projects ([source][4][9]). Latest stable: X.X.X ([source][X]). Kotlin Plugin ≥X.X.X Required for foldable device support ([source][X]). Latest stable: X.X.X-RC ([source][X]). Gradle Wrapper ≥X.X.X Must align with AGP requirements ([source][X][X]).
Recommendations for Flutter Projects
1️⃣ Update
android/build.gradle:plugins { id "com.android.application" version "X.X.X" apply false id "org.jetbrains.kotlin.android" version "X.X.X" apply false }2️⃣ Validate dependencies:
Runflutter analyze --suggestionto detect compatibility issues[1].3️⃣ JDK Version:
Use Java 17+ for AGP ≥X.X[1]. Verify via:flutter doctor -v
Common Pitfalls
- Mixing incompatible AGP/Kotlin versions causes errors like
Unsupported class file major version[1][2].- Declarative plugin syntax (
plugins {}block) is now required for newer Flutter projects[4].For troubleshooting dependency conflicts, use:
./gradlew :app:dependenciesCitations:
- 1: https://docs.flutter.dev/release/breaking-changes/android-java-gradle-migration-guide
- 2: https://discuss.kotlinlang.org/t/failed-to-apply-plugin-kotlin-android/29718
- 3: https://docs.flutter.dev/release/breaking-changes/kotlin-version
- 4: https://docs.flutter.dev/release/breaking-changes/flutter-gradle-plugin-apply
- 5: The Android Gradle plugin supports only Kotlin Gradle plugin version 1.5.20 and higher. Lyokone/flutterlocation#941
- 6: https://plugins.gradle.org/plugin/org.jetbrains.kotlin.android
- 7: https://developer.android.com/build/releases/gradle-plugin
- 8: Your project requires a newer version of the Kotlin Gradle plugin. flutter/flutter#156518
- 9: https://docs.gradle.org/current/userguide/compatibility.html
- 10: https://discuss.gradle.org/t/gradle-build-version-mismatching-in-flutter-project/47957
Action: Validate Plugin Versions for Flutter Compatibility
Please double-check that the plugin versions declared in
mobile-v3/android/settings.gradle.ktsare fully compatible with your Flutter setup:
- Flutter Plugin Loader: 1.0.0
- Android Application Plugin: 8.7.0
- AGP is in the 8.x range confirmed to work with Flutter projects. Ensure your Gradle wrapper (≥8.x) and JDK (Java 17+) meet these requirements.
- Kotlin Android Plugin: 1.8.22
- While this version meets the minimum requirements, some sources now recommend considering a move toward a 2.X.X release. Verify that 1.8.22 remains optimal for your project’s dependency ecosystem.
Review your Gradle configuration and the results from
flutter analyze --suggestionto ensure no compatibility issues arise.mobile-v3/analysis_options.yaml (1)
10-10: LGTM! Standard Flutter lints includedIncluding
package:flutter_lints/flutter.yamlensures adherence to Flutter's recommended coding practices.mobile-v3/android/app/build.gradle.kts (6)
1-6: Plugin Configuration Integrity CheckThe new plugins block correctly applies the Android, Kotlin, and Flutter Gradle plugins. The inline comment about applying the Flutter Gradle Plugin after the Android and Kotlin plugins is clear—please ensure that its position (line 5) is maintained consistently as the project evolves.
8-12: Android Block Basic SetupThis section efficiently defines the application's namespace and sets up the SDK and NDK versions using external Flutter properties. Just verify that properties such as
flutter.compileSdkVersionandflutter.ndkVersionare defined prior to their use.
13-16: Compile Options ConfigurationSetting both the source and target compatibility to JavaVersion.VERSION_11 is a solid choice that aligns with modern Java standards. The configuration here is clean and straightforward.
18-20: Kotlin Options SetupThe Kotlin options are properly configured with the JVM target set to Java 11. Converting the JavaVersion to a String ensures compatibility with the DSL.
22-31: Default Configuration BlockThis block is well-organized, leveraging Flutter's properties for SDK and versioning details. However, note the TODO comment on line 23 regarding the application ID. Before production release, ensure that you replace the placeholder with a unique identifier as recommended by Android development best practices.
42-44: Flutter Module Source PathDefining the Flutter block with a relative source path (
"../..") is clear and effective. Just make sure that this relative path remains valid as the project structure changes over time.mobile-v3/.gitignore (2)
8-8: Ignoring Build ArtifactsThe addition of
.build/ensures that internal build artifacts are not tracked by version control, which helps maintain a cleaner repository.
12-12: Swift Package Manager ArtifactsThe new entry
.swiftpm/effectively ignores Swift Package Manager-related files. This is a sensible addition if these files are generated and not intended for version control.mobile-v3/ios/Runner.xcodeproj/project.pbxproj (1)
498-498:❓ Verification inconclusive
Verify bundle identifier change.
The bundle identifier has been changed to
com.airqo.airqo. This change affects app store distribution and user data. Ensure this is intentional and coordinate with your release management team.Check if this bundle identifier is already registered in App Store Connect and if it matches your other environments:
Also applies to: 515-515, 533-533, 549-549, 680-680, 702-702
🏁 Script executed:
#!/bin/bash # Description: Search for all bundle identifier references to ensure consistency echo "Searching for bundle identifier references..." rg -l "com\.airqo\."Length of output: 1430
Bundle Identifier Update Verification
The bundle identifier in
mobile-v3/ios/Runner.xcodeproj/project.pbxprojhas been updated tocom.airqo.airqo. Our search indicates that references to "com.airqo." exist across multiple areas (iOS, Android, documentation, etc.), which suggests an attempt at consistency. However, please verify that:
com.airqo.airqois the deliberate and correct identifier for this release.- This identifier is registered in App Store Connect and aligns with your other environments.
- The change has been harmonized with the release management team to ensure no adverse effects on app store distribution or user data.
| @@ -59,6 +59,7 @@ | |||
| ignoresPersistentStateOnLaunch = "NO" | |||
| debugDocumentVersioning = "YES" | |||
| debugServiceExtension = "internal" | |||
| enableGPUValidationMode = "1" | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Consider making GPU validation mode configurable.
While enabling GPU validation mode can help catch rendering issues early (especially useful with Google Maps integration), it may impact development performance due to additional validation checks during rendering.
Since this setting is in xcshareddata and affects all developers, consider:
- Moving it to a debug-specific scheme
- Making it configurable via a build configuration
- Documenting when to enable/disable it
Let's verify if this is a recommended setting for shared schemes:
🌐 Web query:
Should GPU validation mode be enabled by default in Xcode shared schemes?
💡 Result:
GPU validation mode in Xcode schemes should not be enabled by default for general use cases, though it depends on the context of development workflows and performance requirements. Here's a breakdown of key considerations:
Debugging vs. Release Builds
- Debug configurations: Enabling GPU validation (via
XCODE_SCHEME_ENABLE_GPU_API_VALIDATIONorXCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION) is recommended during development to catch Metal API misuse and shader errors[4][9]. Tools like Shader Validation help identify out-of-bounds memory access or invalid resource usage[4]. - Release configurations: Validation layers introduce measurable CPU overhead[6][9], making them unsuitable for production builds where performance is critical[3][6].
Default Behavior in Xcode
- Xcode schemes historically enabled Metal API Validation by default in debug builds[3][9], but this varies based on project settings.
- The
XCODE_SCHEME_LAUNCH_CONFIGURATIONproperty allows explicit control over build configurations tied to schemes (e.g.,Debug/Release)[1].
Performance Impact
| Scenario | CPU Overhead | GPU Overhead |
|---|---|---|
| Debugging | Moderate[9] | Minimal |
| Production | Unacceptable[3][6] | Unacceptable |
Best Practices
- Enable for debugging: Use schemes with GPU validation active during development to catch errors early[4][9].
- Disable for release: Ensure validation is off in release builds via scheme settings (
XCODE_SCHEME_ENABLE_GPU_API_VALIDATION=NO)[1][3]. - Automate with CI: Integrate validation checks into automated testing pipelines without enabling them in shipped apps[4].
For shared schemes, a balanced approach is to enable GPU validation only in debug configurations by default while excluding it from release builds[1][6]. This aligns with Apple’s guidance to use these tools diagnostically rather than in production[4][9].
Citations:
- 1: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7581
- 2: https://www.youtube.com/watch?v=yazY8hCO46s
- 3: https://gitlab.kitware.com/cmake/cmake/-/issues/23857
- 4: https://developer.apple.com/videos/play/wwdc2020/10616/
- 5: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes
- 6: https://docs.unity3d.com/2020.1/Documentation/Manual/Metal.html
- 7: https://forums.developer.apple.com/forums/thread/727037
- 8: https://github.com/yonaskolb/XcodeGen/blob/master/Docs/ProjectSpec.md
- 9: https://developer.apple.com/documentation/xcode/validating-your-apps-metal-api-usage/
- 10: https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project
GPU Validation Mode Configurability Consideration
While enabling GPU validation mode can help catch rendering issues during development (especially with Google Maps integration), our research confirms that leaving it enabled by default in a shared Xcode scheme is not advisable. This setting can introduce performance overhead and is better suited for debug configurations only. Consider:
- Moving
enableGPUValidationMode = "1"from the shared scheme to a debug-specific scheme, or - Making it configurable via build settings so that it’s only enabled during active GPU debugging sessions.
File: mobile-v3/ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme (line 62)
There was a problem hiding this comment.
create a github issue for this.
There was a problem hiding this comment.
🧩 Analysis chain
@Baalmart I've created a GitHub issue to track the GPU validation mode configuration improvements. The issue includes detailed context about the current state, the problem, proposed solutions, and implementation notes. You'll be assigned to the issue for tracking purposes.
🏁 Script executed:
#!/bin/bash
# Create a GitHub issue for GPU validation mode configuration
gh issue create \
--title "iOS: Make GPU validation mode configurable in Xcode schemes" \
--body "## Current State
The GPU validation mode is currently enabled by default in the shared Xcode scheme for all builds.
\`\`\`diff
debugDocumentVersioning = \"YES\"
debugServiceExtension = \"internal\"
+ enableGPUValidationMode = \"1\"
\`\`\`
## Problem
Having GPU validation mode enabled by default in shared schemes can:
- Introduce measurable CPU overhead during development
- Impact performance in production builds
- Affect all developers using the shared scheme, even when not debugging GPU-related issues
## Proposed Solution
Consider one of these approaches:
1. Move GPU validation mode to a debug-specific scheme
2. Make it configurable via build configuration
3. Document when to enable/disable it in the development workflow
## Implementation Notes
- Review current GPU validation settings across all schemes
- Create separate debug schemes with GPU validation enabled
- Update documentation to reflect GPU validation usage guidelines
## References
- Original PR: https://github.com/airqo-platform/AirQo-frontend/pull/2490
- Discussion: https://github.com/airqo-platform/AirQo-frontend/pull/2490#discussion_r1963518359
## Additional Context
This change aligns with best practices for Metal API validation in iOS development, where validation tools should be used diagnostically rather than enabled by default in production builds." \
--assignee "Baalmart"
Length of output: 1525
@Baalmart I've created issue #2492 to track the GPU validation mode improvements: #2492
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
|
|
||
| @main | ||
| @objc class AppDelegate: FlutterAppDelegate { | ||
| override func application( | ||
| _ application: UIApplication, | ||
| didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? | ||
| ) -> Bool { | ||
| GMSServices.provideAPIKey("YOUR_API_KEY_HERE") |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Replace the placeholder Google Maps API key with a valid key.
The placeholder "YOUR_API_KEY_HERE" will cause Google Maps functionality to fail. This needs to be replaced with a valid API key before deployment.
To ensure the API key is properly configured:
- Check if the key exists in environment variables or secure storage
- Verify the key has the necessary permissions for iOS Maps SDK
🏁 Script executed:
#!/bin/bash
# Description: Check for potential API key configuration files
# Note: Actual key should not be hardcoded in the source code
echo "Searching for potential API key configuration files..."
fd -t f -e plist -e xcconfig -e env . | grep -i "key\|secret\|config"Length of output: 336
Action Required: Replace the hardcoded placeholder API key.
The current line in mobile-v3/ios/Runner/AppDelegate.swift still hardcodes "YOUR_API_KEY_HERE", which will cause Google Maps functionality to fail in production. Please update this by one of the following approaches:
- Use a valid API key: Replace the placeholder with a secure, valid API key that has the necessary permissions for the iOS Maps SDK.
- Load dynamically from configuration: If the intention is to manage keys via configuration files (e.g., those found in
mobile-v3/ios/Flutter/Debug.xcconfigandRelease.xcconfig), modify the code to load the API key dynamically from the appropriate config (or from the Info.plist/environment variables) rather than hardcoding it.
Make sure to verify that the final deployed key is secure and correctly configured for your build environment.
There was a problem hiding this comment.
Hi @Mozart299 please review this issue. @Mozart299
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
mobile-v3/ios/Podfile
Outdated
|
|
||
| pod 'GoogleMaps', '9.0.0' |
There was a problem hiding this comment.
Remove duplicate GoogleMaps pod declaration.
The GoogleMaps pod is declared twice with different version specifications:
- Root level:
pod 'GoogleMaps', '9.0.0' - Target level:
pod 'GoogleMaps'
This could lead to version conflicts.
Keep only one declaration, preferably in the target block with the specific version:
-pod 'GoogleMaps', '9.0.0'
target 'Runner' do
use_frameworks!
- pod 'GoogleMaps'
+ pod 'GoogleMaps', '9.0.0'Also applies to: 34-34
mobile-v3/ios/Podfile
Outdated
| @@ -1,6 +1,7 @@ | |||
| # Uncomment this line to define a global platform for your project | |||
| platform :ios, '14.0' | |||
| platform :ios, '15.0' | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify iOS 15.0 platform requirement.
Updating the minimum iOS version to 15.0 might exclude users with older devices. Consider the impact on your user base.
Let's check the iOS version distribution among users:
🌐 Web query:
What is the current iOS version distribution and what percentage of users are still on iOS 14 or lower?
💡 Result:
As of February 2025, Apple’s latest major release iOS 18 dominates device adoption with ~79–80% market share, while iOS 17 accounts for ~14–15%. Older versions like iOS 16 and below now represent less than 6% combined[2][3][4].
Key Distribution Highlights:
- iOS ≥18: 79–80% (with subversions like iOS 18.1 alone accounting for ~45%)[3][5][9]
- iOS ≥17: Cumulative adoption reaches ~94–95%, including both major versions[3][10].
- iOS ≤14: Now represents <1% of active devices[2][4][10].
Breakdown of Older Versions:
| Version | Adoption (Jan–Feb ’25) | Notes |
|---|---|---|
| iOS ≤14 | <1% | Mostly legacy devices like iPhone SE (1st gen), iPhone X[4][10]. |
| iOS ≤16 | ~6% | Includes devices incompatible with newer OS updates[3][4]. |
Apple’s aggressive update policies and strong user adoption trends ensure rapid migration to newer OS versions[7][10]. Developers are advised to set minimum deployment targets to iOS ≥16 to cover >96% of active users while leveraging modern APIs[2][7].
Citations:
- 1: https://en.wikipedia.org/wiki/IOS_version_history
- 2: https://telemetrydeck.com/blog/ios-market-share-02-24/
- 3: https://telemetrydeck.com/survey/apple/iOS/majorSystemVersions/
- 4: https://iosref.com/ios-usage
- 5: https://gs.statcounter.com/ios-version-market-share/
- 6: https://scoop.market.us/iphone-users-statistics/
- 7: https://www.businessofapps.com/data/ios-version-adoption-rates/
- 8: https://gs.statcounter.com/os-market-share/mobile/worldwide
- 9: https://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide/
- 10: https://www.statista.com/statistics/565270/apple-devices-ios-version-share-worldwide/
Action Required: Resolve Deployment Target & Duplicate Pod Declarations
-
iOS Deployment Target:
The current setting (platform :ios, '15.0') drops support for devices running iOS 14 or below. Based on recent reports, less than 1% of users are on iOS 14 or lower. Although this cutoff may be acceptable, consider whether raising the minimum to iOS 16 could better align with modern API usage and industry best practices. -
Duplicate GoogleMaps Pod Declarations:
There are two separate declarations for theGoogleMapspod:- A root-level declaration with an explicit version (
pod 'GoogleMaps', '9.0.0') - A declaration inside the target block without specifying a version
These duplications might lead to conflicts. It is recommended to consolidate them into a single, consistent declaration.
- A root-level declaration with an explicit version (
There was a problem hiding this comment.
Hi @Mozart299 , I have left a few review comments on your PR, please review them accordingly. Thanks for the great work.
|
|
||
| @main | ||
| @objc class AppDelegate: FlutterAppDelegate { | ||
| override func application( | ||
| _ application: UIApplication, | ||
| didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? | ||
| ) -> Bool { | ||
| GMSServices.provideAPIKey("YOUR_API_KEY_HERE") |
There was a problem hiding this comment.
Hi @Mozart299 please review this issue. @Mozart299
| @@ -5,7 +5,7 @@ | |||
| <key>CFBundleDevelopmentRegion</key> | |||
| <string>$(DEVELOPMENT_LANGUAGE)</string> | |||
| <key>CFBundleDisplayName</key> | |||
| <string>AirQo</string> | |||
| <string>Airqo</string> | |||
There was a problem hiding this comment.
Supposed to be AirQo and NOT Airqo.
Summary of Changes (What does this PR do?)
Status of maturity (all need to be checked before merging):
How should this be manually tested?
What are the relevant tickets?
Screenshots (optional)
Summary by CodeRabbit
New Features
Chores