Hi — we're trying to migrate from the legacy AdButler CocoaPod (1.0.8) to the new SPM SDK and ran into two blockers.
1. The new SDK on main has no tag or release
The README documents the new API (AdButler.configure(accountId:), AdButlerBannerView, AdButlerInterstitialAd, AdButlerNativeAd, AdButlerVASTPlayer, etc.). But:
- Latest tag is
1.0.8 (commit 622237bb), which is the pre-rewrite code — none of the documented APIs exist there.
- The new SDK code only lives on
main at SHA 92230d5fa7fb11e73cbf4b1bc64657e81d1c0bfb, untagged.
- README's installation instructions are misleading as a result:
.package(url: \"...\", from: \"1.0.0\") resolves to 1.0.8 → old code → README examples don't compile.pod 'AdButlerSDK', '~> 1.0' — same issue (and no `AdButlerSDK` podspec appears to be published on trunk).
Consumers currently have to pin to a commit SHA, which means no semver, no release notes, no upgrade path. Could you cut a `2.0.0` (or whatever) tag against the current `main` and publish a GitHub release? Same for the CocoaPods podspec if CocoaPods is still supported.
Related: #10 (SPM support, open since 2023) — looks like the rewrite happened but the release step never finished.
2. No public fetch-only API
`AdButlerClient.fetchAd(request:accountId:) async throws -> AdResponse` is exactly the API we need — but the class is `internal`, so we can't call it.
The public surface is entirely rendering components (`AdButlerBannerView`, `AdButlerInterstitialAd`, etc.) that fetch + render in one step. Our app has a marketplace screen that pre-fetches ad data and injects it into pre-existing custom `UITableViewCell` subclasses styled to match the product list. We can't drop in `AdButlerBannerView` without rewriting every banner cell.
Would you consider promoting a fetch-only entry point to public API? Something like:
```swift
public extension AdButler {
static func fetchAd(request: AdRequest) async throws -> AdResponse
}
```
That would let apps with existing UI keep their rendering and still get the SDK's benefits (response parsing, tracking pixels, viewability hooks, frequency capping) — instead of having to reimplement those against the public ad-serve endpoint with `URLSession` directly, which is what we've ended up doing.
Happy to open a PR for the public fetch API if you'd be open to merging it.
Thanks!
Hi — we're trying to migrate from the legacy
AdButlerCocoaPod (1.0.8) to the new SPM SDK and ran into two blockers.1. The new SDK on
mainhas no tag or releaseThe README documents the new API (
AdButler.configure(accountId:),AdButlerBannerView,AdButlerInterstitialAd,AdButlerNativeAd,AdButlerVASTPlayer, etc.). But:1.0.8(commit622237bb), which is the pre-rewrite code — none of the documented APIs exist there.mainat SHA92230d5fa7fb11e73cbf4b1bc64657e81d1c0bfb, untagged..package(url: \"...\", from: \"1.0.0\")resolves to1.0.8→ old code → README examples don't compile.pod 'AdButlerSDK', '~> 1.0'— same issue (and no `AdButlerSDK` podspec appears to be published on trunk).Consumers currently have to pin to a commit SHA, which means no semver, no release notes, no upgrade path. Could you cut a `2.0.0` (or whatever) tag against the current `main` and publish a GitHub release? Same for the CocoaPods podspec if CocoaPods is still supported.
Related: #10 (SPM support, open since 2023) — looks like the rewrite happened but the release step never finished.
2. No public fetch-only API
`AdButlerClient.fetchAd(request:accountId:) async throws -> AdResponse` is exactly the API we need — but the class is `internal`, so we can't call it.
The public surface is entirely rendering components (`AdButlerBannerView`, `AdButlerInterstitialAd`, etc.) that fetch + render in one step. Our app has a marketplace screen that pre-fetches ad data and injects it into pre-existing custom `UITableViewCell` subclasses styled to match the product list. We can't drop in `AdButlerBannerView` without rewriting every banner cell.
Would you consider promoting a fetch-only entry point to public API? Something like:
```swift
public extension AdButler {
static func fetchAd(request: AdRequest) async throws -> AdResponse
}
```
That would let apps with existing UI keep their rendering and still get the SDK's benefits (response parsing, tracking pixels, viewability hooks, frequency capping) — instead of having to reimplement those against the public ad-serve endpoint with `URLSession` directly, which is what we've ended up doing.
Happy to open a PR for the public fetch API if you'd be open to merging it.
Thanks!