Skip to content

Conversation

@ChiragAgg5k
Copy link
Member

@ChiragAgg5k ChiragAgg5k commented Nov 28, 2025

This PR contains updates to the Apple SDK for version 13.5.0.

Summary by CodeRabbit

  • New Features

    • Screenshot capture functionality added to Avatars service with customizable viewport, rendering parameters, theme selection, timezone support, and multiple output formats
    • New Theme (light/dark) and Timezone configuration enums introduced
  • Documentation

    • Version upgraded to 13.5.0 with updated changelog
    • Added usage examples for screenshot feature
  • Other Updates

    • Updated MFA endpoint paths

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Nov 28, 2025

Walkthrough

This PR bumps the SDK to 13.5.0 and documents the change in CHANGELOG and README. It adds a new Avatars.getScreenshot(...) method that accepts a URL and many optional rendering parameters (viewport, scale, theme, userAgent, fullPage, locale, timezone, geolocation, permissions, dimensions, quality, output) and returns raw bytes. Three enums were added: Theme, Output, and Timezone. Client.swift now exposes JSONCodable via @_exported and updates the x-sdk-version header. An example doc for avatars/get-screenshot was added and several Account MFA endpoint paths were adjusted.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Sources/AppwriteEnums/Timezone.swift: validate completeness and correctness of many IANA timezone cases.
  • Sources/Appwrite/Services/Avatars.swift: verify parameter names/types, request construction, and endpoint path.
  • Sources/Appwrite/Client.swift: review the new @_exported import JSONCodable and updated x-sdk-version header.
  • Sources/Appwrite/Services/Account.swift: confirm the changed MFA endpoint paths (/account/mfa/challenges) are intentional and consistent with server API.
  • README/CHANGELOG/docs/examples: ensure version strings and example usage match the new API surface.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately captures the main objective of the pull request—an SDK version update to 13.5.0—and is specific and concise.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch dev

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
Sources/AppwriteEnums/Theme.swift (1)

3-5: Consider omitting redundant string enum values.

SwiftLint correctly identifies that explicit raw values can be omitted when they match the case name. However, since this SDK is auto-generated, maintaining explicit values may be intentional for clarity or generator consistency.

-public enum Theme: String, CustomStringConvertible {
-    case light = "light"
-    case dark = "dark"
+public enum Theme: String, CustomStringConvertible {
+    case light
+    case dark
Sources/Appwrite/Services/Avatars.swift (1)

293-382: New getScreenshot endpoint wiring looks consistent with existing Avatars APIs

The overall shape of the method (path construction, apiParams, inclusion of project, and GET call) is consistent with the rest of the service and should integrate cleanly. Using the new enums (Theme, Timezone, Output) directly in apiParams also aligns with the CustomStringConvertible pattern introduced for them.

Two minor improvement points:

  1. Tighten the headers type and docs if possible

    Exposing headers as Any? in a public API makes it hard for callers to know what shape is actually expected and can hide misuse until runtime (depending on how parametersToQueryString encodes values). If the backend expects a concrete structure (e.g. [String: String], or an array of { name, value } objects), it would be better to:

    • Use a more specific Swift type instead of Any?, and
    • Update the doc comment from “headers: Any (optional)” to describe the exact expected format.

    That keeps this API more discoverable and type‑safe, and also ensures whatever encoding the client does for GET query parameters matches what the backend expects.

  2. (Optional) Consider an options type for the growing parameter list

    This method now has a long list of optional, mostly configuration-like parameters. For future major versions (or if the generator allows), consider introducing something like ScreenshotOptions and accepting a single options value instead of many positional arguments. That would make call sites more readable and easier to extend without constantly expanding the signature.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 18b675b and c3d34d3.

📒 Files selected for processing (8)
  • CHANGELOG.md (1 hunks)
  • README.md (1 hunks)
  • Sources/Appwrite/Client.swift (2 hunks)
  • Sources/Appwrite/Services/Avatars.swift (1 hunks)
  • Sources/AppwriteEnums/Output.swift (1 hunks)
  • Sources/AppwriteEnums/Theme.swift (1 hunks)
  • Sources/AppwriteEnums/Timezone.swift (1 hunks)
  • docs/examples/avatars/get-screenshot.md (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
Sources/Appwrite/Services/Avatars.swift (1)
Sources/Appwrite/Client.swift (1)
  • call (302-333)
🪛 markdownlint-cli2 (0.18.1)
docs/examples/avatars/get-screenshot.md

11-11: Bare URL used

(MD034, no-bare-urls)

🪛 SwiftLint (0.57.0)
Sources/AppwriteEnums/Theme.swift

[Warning] 4-4: String enum values can be omitted when they are equal to the enumcase name

(redundant_string_enum_value)


[Warning] 5-5: String enum values can be omitted when they are equal to the enumcase name

(redundant_string_enum_value)

🔇 Additional comments (7)
README.md (1)

34-34: Version update looks good.

The Swift Package Manager dependency version is correctly updated to 13.5.0, consistent with the SDK version in Client.swift and the CHANGELOG entry.

CHANGELOG.md (1)

3-5: LGTM!

The changelog entry correctly documents the new getScreenshot method addition.

Sources/Appwrite/Client.swift (2)

8-8: Public re-export of JSONCodable added.

Using @_exported makes all JSONCodable symbols publicly available to consumers of this SDK without requiring them to explicitly import it. This is a public API surface expansion.

Verify this is intentional - consumers will now have implicit access to JSONCodable types. If JSONCodable is only used internally, a regular import would be more appropriate to avoid polluting the consumer's namespace.


27-27: Version header updated correctly.

The SDK version header is properly bumped to 13.5.0.

Sources/AppwriteEnums/Output.swift (1)

1-15: LGTM!

The Output enum correctly defines supported image formats for the screenshot API. The inclusion of both jpg and jpeg cases likely reflects API compatibility requirements.

docs/examples/avatars/get-screenshot.md (1)

10-31: Example documentation looks complete.

The example demonstrates all available parameters for getScreenshot. The markdownlint warning about the bare URL on line 11 is a false positive since it's a code parameter value within a code block.

Some parameter values appear to be boundary/edge cases (e.g., scale: 0.1, quality: -1, width: 0, height: 0). Verify these are valid API values or consider using more realistic example values that users would typically specify.

Sources/AppwriteEnums/Timezone.swift (1)

3-426: I'll help you verify the timezone format concern. Let me search the codebase to understand if the lowercase format is intentional or if it needs to match standard IANA conventions.
<function_calls>

#!/bin/bash

Search for timezone-related code and usage patterns

find . -type f -name "*.swift" | head -20


</function_calls>

Let me search more specifically for timezone-related code and API usage:
<function_calls>

#!/bin/bash

Look for files that reference timezone or Timezone

rg -l "Timezone|timezone" --type swift | head -20


</function_calls>

Now let me check how timezones are actually used in API calls and if there's any documentation about the format:
<function_calls>

#!/bin/bash

Search for usage of the Timezone enum

rg "Timezone." --type swift -C 2 | head -50


</function_calls>

Let me also check if there are any tests or examples showing timezone format:
<function_calls>

#!/bin/bash

Look for timezone format in test files or examples

rg "africa|america|europe|asia|pacific|atlantic|indian|antarctica|arctic" --type swift -i | grep -i "timezone|rawvalue" | head -20


</function_calls>

Let me search for documentation files or README that might explain the timezone format:
<function_calls>

#!/bin/bash

Check for documentation files

find . -type f ( -name "README*" -o -name ".md" -o -name ".txt" ) | head -20


</function_calls>

Let me check the git history to see if there are any comments about why this format was chosen:
<function_calls>

#!/bin/bash

Look at the Timezone.swift file structure and comments

head -100 Sources/AppwriteEnums/Timezone.swift


</function_calls>

Let me verify the actual raw values more carefully:
<function_calls>

#!/bin/bash

Extract and analyze the raw values to confirm the format pattern

grep '= "' Sources/AppwriteEnums/Timezone.swift | head -30


</function_calls>

Let me search for any backend API code that might give hints about expected timezone format:
<function_calls>

#!/bin/bash

Look for API or networking code

find . -type f -name "*.swift" | xargs grep -l "request|api|client" -i | head -10


</function_calls>

Let me check if there's a similar enum or pattern in other Appwrite SDK implementations:
<function_calls>

#!/bin/bash

Look for other enum files to understand the pattern

find . -type f -name "Enum.swift" -o -name "enum.swift" | head -10


</function_calls>

Let me look for API documentation or specs:
<function_calls>

#!/bin/bash

Search for timezone format references in any documentation

rg "timezone" --type md -i -C 2


</function_calls>

Let me check one more thing - look at the directory structure and see if there's any related documentation:
<function_calls>

#!/bin/bash

Check directory structure and look for documentation

ls -la | head -20
find . -maxdepth 2 -type f -name ".md" -o -name ".txt"


</function_calls>

Let me verify the format one more time and check for any variations:
<function_calls>

#!/bin/bash

Count and verify the timezone format consistency

grep 'case ' Sources/AppwriteEnums/Timezone.swift | wc -l

Check if all use lowercase with forward slashes

grep 'case .* = "[a-z_/]*"' Sources/AppwriteEnums/Timezone.swift | wc -l

Look for any that don't match the pattern

grep 'case ' Sources/AppwriteEnums/Timezone.swift | grep -v '= "[a-z_/]*"' | head -10


</function_calls>

Let me search for any references to IANA or timezone standards:
<function_calls>

#!/bin/bash

Search for IANA, timezone database, or similar references

rg "IANA|zone|database|format|standard" --type swift -i | grep -i "timezone|tz" | head -20


</function_calls>

Let me check if this is an Appwrite SDK and look for backend integration:
<function_calls>

#!/bin/bash

Look for Appwrite-specific files or references

find . -type f -name "*.swift" | xargs grep -l "appwrite" -i | head -10


</function_calls>

Let me check the git log for the Timezone.swift file to see if there's context about why this format was chosen:
<function_calls>

#!/bin/bash

Check git log for Timezone.swift

git log --oneline Sources/AppwriteEnums/Timezone.swift | head -10


</function_calls>

Let me verify the complete list of values to see the format:
<function_calls>

#!/bin/bash

Show all timezone values with their format

grep '= "' Sources/AppwriteEnums/Timezone.swift | sed 's/.= "(.)".*/\1/' | sort | uniq -c | head -30


</function_calls>

Now let me check if there are test files that validate this format:
<function_calls>

#!/bin/bash

Look for test files

find . -type f -name "Test" -o -name "test" -o -name "spec" | grep -i swift


</function_calls>

Let me verify what the standard IANA timezone format actually is and if the lowercase version is acceptable:
<function_calls>

IANA timezone database format standard Africa/Addis_Ababa vs africa/addis_ababa case sensitivity
</function_calls>

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c3d34d3 and 53f073c.

📒 Files selected for processing (3)
  • CHANGELOG.md (1 hunks)
  • Sources/Appwrite/Services/Account.swift (4 hunks)
  • docs/examples/avatars/get-screenshot.md (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • CHANGELOG.md
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/examples/avatars/get-screenshot.md

11-11: Bare URL used

(MD034, no-bare-urls)

🔇 Additional comments (1)
docs/examples/avatars/get-screenshot.md (1)

1-35: Example is accurate and comprehensive; consider auth header guidance as optional improvement.

The example correctly demonstrates all available parameters for the getScreenshot method. Verification confirms the method signature matches the example exactly—all parameters shown are supported, including geolocation (latitude, longitude, accuracy) and permissions.

One optional suggestion: consider using a placeholder like "Bearer YOUR_TOKEN_HERE" for the Authorization header to encourage developers to use their own credentials rather than copy-pasting the example token directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants