Tracker: production-ready / first tagged release (bdk-dart 1.0.0)

[reez]

This issue tracks the bar for the first tagged/stable bdk-dart release and also collects feedback from real integrations about what they consider production-ready. Items here are release criteria for bdk-dart itself, not necessarily blockers for downstream apps shipping on the current 2.3.x line.

Feel free to add anything you think is required:

Open Items

• First tagged bdk-dart release targets bdk-ffi 3.x
  • main is on bdk-ffi v3.0.0 via bdk-ffi 3.0.0 #70
  • first RC tag is cut from that baseline
  • stable 1.0.0 tag is cut after RC validation
  • publish library to pub.dev

Open Questions

• Track web target support strategy and feasibility (Track web target support strategy for bdk-dart #40)

Active work

• Improve example app to MVP-level developer reference (Example mobile app #5)
• Prebuilt binaries path with verification and fallback (auto | always | never) (Support prebuilt binaries as default (with opt-in source builds) #20)

Done

• Baseline CI workflow exists (format/analyze/test/demo analyze) (Add CI workflows #10)
• Fix example resource-disposal bug(s) (Ensure ElectrumClient is always disposed on failure in network_example.dart #14)
• Define and document supported platform/architecture matrix (Define and publish supported target matrix for bdk-dart #24)
• Pub.dev readiness (metadata, publishing steps, release checklist) (Pub.dev release readiness checklist for bdk-dart #28)
• Add CI compatibility checks against upstream bdk-ffi changes (Add CI compatibility check against upstream bdk-ffi changes #30)
• Add integration test harness for network-based client tests (Add integration test harness for network-based client tests #31)
• Add missing CI coverage for target matrix builds (Expand CI to validate target matrix builds (Windows + Flutter mobile smoke) #25)
• Add integration tests for Electrum sync/apply/persist flow (Add integration test coverage for Electrum sync/apply/persist flow #26)
• Add integration tests for Esplora sync/apply/persist flow (Add integration test coverage for Esplora sync/apply/persist flow #27)
• Track and move to bdk-ffi 2.3 release tags when available (Track bdk-ffi 2.3 release and switch pinned deps #18)
• API ergonomics improvements (named-argument-friendly surface) (Named arguments for easiness of use #21)
• UniFfi::UnexpectedEnumCase uniffi-dart (bug: wallet.transactions() may throw UniFfi::UnexpectedEnumCase due to ChainPosition converter offset accounting #46)
• Execute pub.dev release metadata + dry-run checklist (Execute pub.dev release metadata and publish dry-run #43)

[Saleciani]

If you can also target web, it would be very interesting for applications that can be done.

Bitcoin wallets suffer from censorship in many jurisdictions in app stores, having web versions easily helps :)

[reez]

If you can also target web, it would be very interesting for applications that can be done.

Bitcoin wallets suffer from censorship in many jurisdictions in app stores, having web versions easily helps :)

absolutely awesome suggestion, added

[j-kon]

Been going through this from a Flutter/mobile perspective.

I think the checklist here already covers most of the core pieces. The two areas that feel most critical from my side are:

• Developer experience (especially around setup and minimizing Rust friction)
• The reference app (making it something that actually demonstrates real wallet flows, not just structure)

If those two are strong, it makes everything else much easier for people building on top.

Also feels like once the reference app is solid, it naturally becomes the best form of documentation for how things are expected to work in practice.

[reez]

Been going through this from a Flutter/mobile perspective.

I think the checklist here already covers most of the core pieces. The two areas that feel most critical from my side are:

• Developer experience (especially around setup and minimizing Rust friction)
• The reference app (making it something that actually demonstrates real wallet flows, not just structure)

If those two are strong, it makes everything else much easier for people building on top.

Also feels like once the reference app is solid, it naturally becomes the best form of documentation for how things are expected to work in practice.

this is good feedback. I think we should have those 2 critical items done if we do #5 #20 but let me know if there are specific Issues we can open up related to DevX to track+implement.

[j-kon]

Been going through this from a Flutter/mobile perspective.
I think the checklist here already covers most of the core pieces. The two areas that feel most critical from my side are:

• Developer experience (especially around setup and minimizing Rust friction)
• The reference app (making it something that actually demonstrates real wallet flows, not just structure)

If those two are strong, it makes everything else much easier for people building on top.
Also feels like once the reference app is solid, it naturally becomes the best form of documentation for how things are expected to work in practice.

this is good feedback. I think we should have those 2 critical items done if we do #5 #20 but let me know if there are specific Issues we can open up related to DevX to track+implement.

Hi @reez, I was looking through #20 and noticed there’s already an open implementation PR here: #22.

It looks like the PR covers the main direction discussed in this issue:

• precompiled binaries
• auto | always | never modes
• verification/signing
• fallback to source builds
• docs/tests

From what I can see, it may now mainly need a rebase/conflict cleanup and review follow-up before it can move again.

Would it be helpful for me to help with a smaller piece around this, such as:

• reviewing the current PR and summarizing what still needs attention
• helping with docs or troubleshooting notes
• opening a smaller follow-up issue for any DevX gaps that are separate from the main prebuilt-binaries implementation

I’d be happy to help move this forward if needed. I don’t want to duplicate the existing work in #22, so I wanted to check what would be most useful before jumping in.

[reez]

Been going through this from a Flutter/mobile perspective.
I think the checklist here already covers most of the core pieces. The two areas that feel most critical from my side are:

• Developer experience (especially around setup and minimizing Rust friction)
• The reference app (making it something that actually demonstrates real wallet flows, not just structure)

If those two are strong, it makes everything else much easier for people building on top.
Also feels like once the reference app is solid, it naturally becomes the best form of documentation for how things are expected to work in practice.

this is good feedback. I think we should have those 2 critical items done if we do #5 #20 but let me know if there are specific Issues we can open up related to DevX to track+implement.

Hi @reez, I was looking through #20 and noticed there’s already an open implementation PR here: #22.

It looks like the PR covers the main direction discussed in this issue:

• precompiled binaries
• auto | always | never modes
• verification/signing
• fallback to source builds
• docs/tests

From what I can see, it may now mainly need a rebase/conflict cleanup and review follow-up before it can move again.

Would it be helpful for me to help with a smaller piece around this, such as:

• reviewing the current PR and summarizing what still needs attention
• helping with docs or troubleshooting notes
• opening a smaller follow-up issue for any DevX gaps that are separate from the main prebuilt-binaries implementation

I’d be happy to help move this forward if needed. I don’t want to duplicate the existing work in #22, so I wanted to check what would be most useful before jumping in.

Yeah that would be great to have someone other than my self review #22 , and summarize what still needs attention or help with any troubleshooting on it

[j-kon]

Sounds good, I’ll take a closer look at #22 and put together a review summary covering what still needs attention, any obvious conflicts/failures, and possible troubleshooting areas.

I’ll keep it focused on helping move the existing PR forward rather than duplicating the implementation.

Been going through this from a Flutter/mobile perspective.
I think the checklist here already covers most of the core pieces. The two areas that feel most critical from my side are:

• Developer experience (especially around setup and minimizing Rust friction)
• The reference app (making it something that actually demonstrates real wallet flows, not just structure)

If those two are strong, it makes everything else much easier for people building on top.
Also feels like once the reference app is solid, it naturally becomes the best form of documentation for how things are expected to work in practice.

this is good feedback. I think we should have those 2 critical items done if we do #5 #20 but let me know if there are specific Issues we can open up related to DevX to track+implement.

Hi @reez, I was looking through #20 and noticed there’s already an open implementation PR here: #22.
It looks like the PR covers the main direction discussed in this issue:

• precompiled binaries
• auto | always | never modes
• verification/signing
• fallback to source builds
• docs/tests

From what I can see, it may now mainly need a rebase/conflict cleanup and review follow-up before it can move again.
Would it be helpful for me to help with a smaller piece around this, such as:

• reviewing the current PR and summarizing what still needs attention
• helping with docs or troubleshooting notes
• opening a smaller follow-up issue for any DevX gaps that are separate from the main prebuilt-binaries implementation

I’d be happy to help move this forward if needed. I don’t want to duplicate the existing work in #22, so I wanted to check what would be most useful before jumping in.

Yeah that would be great to have someone other than my self review #22 , and summarize what still needs attention or help with any troubleshooting on it

Sounds good, I’ll take a closer look at #22 and put together a review summary covering what still needs attention, any obvious conflicts/failures, and possible troubleshooting areas.

I’ll keep it focused on helping move the existing PR forward rather than duplicating the implementation.

[Johnosezele]

suggested addition to the checklist:

• publish library to pub.dev