Skip to content

Commit

Permalink
fix: lint
Browse files Browse the repository at this point in the history
  • Loading branch information
NathanWalker committed Jan 21, 2025
1 parent 70d26ea commit 4ac2355
Show file tree
Hide file tree
Showing 2 changed files with 12 additions and 11 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -494,8 +494,9 @@ const webpack = require('@nativescript/webpack')

module.exports = (env) => {
webpack.init(env)
env.appComponents = (env.appComponents || []).concat(['./src/activity.android'])

env.appComponents = (env.appComponents || []).concat([
'./src/activity.android',
])

return webpack.resolveConfig()
}
Expand Down
18 changes: 9 additions & 9 deletions content/guide/platform-version-handling.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,11 +36,11 @@ android {
Every year, platforms often bump minimum requirements for public store deployments to be accepted which can often be seen [here for Google](https://developer.android.com/google/play/requirements/target-sdk). For example, it may be stated like this:

> New apps and app updates must target Android 14 (API level 34) or higher to be submitted to Google Play; except for Wear OS and Android TV apps, which must target Android 13 (API level 33) or higher.
Existing apps must target Android 13 (API level 33) or higher to remain available to new users on devices running Android OS higher than your app's target API level.
> Existing apps must target Android 13 (API level 33) or higher to remain available to new users on devices running Android OS higher than your app's target API level.
It's good to refer to these platform docs from time to time (*email notifications are also often sent to Play Store accounts on these evolving requirements*) to ensure your app's targets keep up with store requirements.
It's good to refer to these platform docs from time to time (_email notifications are also often sent to Play Store accounts on these evolving requirements_) to ensure your app's targets keep up with store requirements.

2. `before-plugins.gradle`: (*optional*) Some plugins may fallback to gradle configured versions which you can define here to also help align with app build configuration targets.
2. `before-plugins.gradle`: (_optional_) Some plugins may fallback to gradle configured versions which you can define here to also help align with app build configuration targets.

We can specify additional gradle versions as follows:

Expand Down Expand Up @@ -90,7 +90,7 @@ The [@nativescript/ios](https://github.com/NativeScript/ios) dependency is good
Beyond that, there are 2 key iOS files in your project to keep an eye on with platform versioning over time:
- `App_Resources/iOS/build.xcconfig`: Sets minimum iOS deployment version
- `App_Resources/iOS/build.xcconfig`: Sets minimum iOS deployment version
We can specify the minimum target as follows:
Expand All @@ -102,9 +102,9 @@ Every year, platforms often bump minimum requirements for public store deploymen
> All iOS and iPadOS apps uploaded to App Store Connect must be built with a minimum of Xcode 15 and the iOS 17 SDK. Starting April 2025, all iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS 18 SDK.
It's good to refer to these platform docs from time to time (*email notifications are also often sent to App Store accounts on these evolving requirements*) to ensure your app's targets keep up with store requirements.
It's good to refer to these platform docs from time to time (_email notifications are also often sent to App Store accounts on these evolving requirements_) to ensure your app's targets keep up with store requirements.
- `App_Resources/iOS/Podfile`: (*optional*) If your project brings in plugins that involve [Cocoapods](https://cocoapods.org/) it's a good idea to have one of these. It can help align platform version minimums to match your build.xcconfig.
- `App_Resources/iOS/Podfile`: (_optional_) If your project brings in plugins that involve [Cocoapods](https://cocoapods.org/) it's a good idea to have one of these. It can help align platform version minimums to match your build.xcconfig.

We can make our `Podfile` match our build.xcconfig target versions as follows:

Expand All @@ -116,7 +116,7 @@ post_install do |installer|
target.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '17.0'
end
end
end
end
```

Expand Down Expand Up @@ -152,7 +152,7 @@ A. Set an `IPHONEOS_DEPLOYMENT_TARGET` in your `App_Resource/iOS/build.xcconfig`
IPHONEOS_DEPLOYMENT_TARGET = 17.0;
```
B. Make a change to source code to properly wrap the implementations with [availability](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/#Availability-Condition) decorators to ensure that platform version specific code does not cause an issue if your app is run on an older devicie. You can use [patch-package](https://www.npmjs.com/package/patch-package) to create the diff to manage custom source code changes made to plugins.
B. Make a change to source code to properly wrap the implementations with [availability](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/#Availability-Condition) decorators to ensure that platform version specific code does not cause an issue if your app is run on an older devicie. You can use [patch-package](https://www.npmjs.com/package/patch-package) to create the diff to manage custom source code changes made to plugins.
```
var body: some View {
Expand All @@ -161,7 +161,7 @@ var body: some View {
// ... something only available on iOS 17 or newer
}
} else {
// fallback
// fallback
EmptyView()
}
}
Expand Down

0 comments on commit 4ac2355

Please sign in to comment.